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FOREWORD 


A  true  systems  engineering  approach  will  account  for  all  pieces  of  the  system  being 
developed  -  the  hardware,  the  software,  and  the  people.  The  users  and  maintained  of  the 
systems,  however,  are  frequently  underrepresented  in  system  development.  A  primary 
goal  of  the  ONR  (Office  of  Naval  Research)/SC-21  (Surface  Combatant  for  the 
21st  Century)  Science  &  Technology  Manning  Affordability  Initiative  was  to  promote  the 
inclusion  of  human  roles,  capabilities,  and  limitations  in  the  design  process.  This  report 
is  the  direct  result  of  a  research  effort  in  that  area  and  is  a  follow-up  to  participation  in  the 
1998  revision  of  the  IEEE  1 220  Standard  for  Application  and  Management  of  the 
Systems  Engineering  Process. 

Progress  in  incorporating  the  users  in  the  design  of  systems  requires  concentrated  effort 
from  both  the  systems  engineering  and  human  engineering  communities.  Common 
terminology  and  compatible  processes  must  be  developed.  This  report  identifies  key 
areas  in  which  communication  and  cooperation  between  systems  engineers  and  human 
engineers  are  critical.  Without  these  important  interactions,  the  systems  being  designed 
today  will  not  fit  the  needs,  capabilities,  and  limitations  of  the  users  and  maintainers  of 
tomorrow,  handicapping  our  ability  to  meet  affordability,  flexibility,  and  knowledge 
superiority  requirements  for  the  21st  Century  Fleet. 


Approved  by: 
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EXECUTIVE  SUMMARY 

To  be  successful,  a  systems  engineering  effort  must  integrate  relevant  design  disciplines 
and  effectively  balance  available  resources  and  required  capabilities.  The  development 
of  a  system  must  include  consideration  of  all  its  components  and  how  to  integrate  them, 
including  human  users,  operators,  and  maintainers.  Since  overall  system  performance 
capabilities  are  impacted  by  and  depend  upon  human  performance,  good  systems 
engineering  should  incorporate  good  human  engineering  practices. 

Humans  are  included  in  systems  for  many  different  reasons  -  they  are  intuitive,  flexible, 
and  capable  of  many  functions  and  tasks.  But  at  the  same  time,  humans  are  the  most 
variable  component  of  a  system.  But  the  limitations  inherent  in  human  cognitive  and 
physical  capabilities  mean  that  people  are  commonly  the  least  flexible  and  “designable” 
piece  of  the  total  system.  Due  to  behavioral  unpredictability  and  other  difficulties  in 
quantifying  their  performance  and  characteristics,  humans  are  often  neglected  in  design 
considerations.  Such  practices  result  in  systems  that  are  more  difficult  to  use,  more 
problematic  for  training,  and  less  effective  overall  than  they  should  be.  Once  such  a 
system  is  produced,  the  human  traits  of  flexibility  and  adaptability  must  be  utilized  to 
create  and  employ  system  deficiency  “workarounds.” 

This  report  was  produced  to  provide  guidance  on  how  human  engineering  practices  might 
be  better  incorporated  into  systems  engineering  processes.  The  intended  audience 
includes  developers,  engineers,  and  integrators  who  want  to  produce  systems  that  will 
have  greater  capability  through  better  consideration  of  all  users  -  including  operators, 
maintainers,  and  support  personnel.  The  report  is  also  intended  for  human  engineers  and 
human  factors  practitioners  who  want  to  be  able  to  have  a  greater  impact  within  the 
systems  engineering  process. 

The  process  guidance  documented  within  this  report  was  primarily  developed  from  task 
analyses  of  both  systems  engineering  and  human  engineering  processes.  The  systems 
engineering  task  analysis  was  performed  first,  using  sources  that  included  systems 
engineering  standards  such  as  IEEE  1220  and  EIA/IS  632,  the  INCOSE  (International 
Council  on  Systems  Engineering)  systems  engineering  handbook,  and  feedback  from 
practicing  systems  engineers.  The  human  engineering  task  analysis  was  documented  in 
the  context  of  the  systems  engineering  task  analysis.  Tasks,  decisions,  and  information 
that  were  common  between  the  two  processes  served  to  identify  areas  in  which 
interaction  was  required.  The  interactions  that  were  identified  through  the  task  analyses 
can  be  grouped  into  the  eight  categories  listed  below. 

1.  Mission  Analysis 

2.  Requirements  Analysis 

3.  Function  Analysis 

4.  Function  Allocation 

5.  Task  Design  and  Analysis 
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6.  Human  Interface  and  Team  Development 

7.  Performance,  Workload,  and  Training  Level  Estimation 

8.  User  and  Requirements  Reviews 

Although  the  human  engineering  team  should  have  early  and  end-to-end  involvement  in 
the  system  development  process,  the  level  and  criticality  of  human  engineering 
participation  will  vary  between  the  different  design  stages.  Based  on  the  information 
collected  during  the  task  analyses,  four  major  impact  areas  for  human  engineering 
participation  have  been  identified. 

•  User  Involvement  and  Representation 

•  Participation  in  Function  Analysis 

•  Function  Allocation  Decisions 

•  Compatibility  of  Models 

These  major  impact  areas  are  not  meant  to  represent  the  bulk  of  the  human  engineer  s 
work;  they  are  intended  to  represent  the  most  important  ways  in  which  the  human 
engineer  must  interact  with  the  systems  engineer  and  other  designers.  They  represent  key 
interactions  through  which  human  engineering  can  be  better  integrated  within  systems 
engineering. 


USER  INVOLVEMENT  AND  REPRESENTATION 

From  the  perspective  of  the  user  of  a  fielded  product,  the  user  interface  is  the  rest  of  the 
system.  If  the  user  cannot  find  a  particular  function  or  a  piece  of  information,  then  it  may 
as  well  never  have  been  developed.  The  best  way  to  account  for  users  in  system  design  is 
to  determine  their  needs,  design  the  system  to  support  completion  of  their  tasks,  and 
perform  early  and  iterative  evaluation  with  representative  users.  To  accomplish  this, 
scenarios  for  system  use  must  be  defined  from  the  user’s  perspective  and  integrated  into 
the  design  process.  The  best  way  to  get  feedback  from  representative  users  is  to  provide 
them  with  examples  of  how  the  system  would  be  operated  and  what  the  user  interface 
might  include.  User-oriented  scenarios  can  be  excellent  vehicles  for  soliciting  feedback 
during  user  reviews.  Reviewers  and  potential  users  typically  are  able  to  provide  better 
and  more  detailed  feedback  from  a  descriptive  scenario  than  from  a  list  of  requirements 
or  functional  description.  Such  scenarios  may  also  become  the  basis  for  comparative  or 
evaluative  testing  of  the  system  or  the  development  of  user  models  that  describe  user 
tasks,  task  sequences,  and  task  interactions.  In  addition  to  scenarios,  effective  user 
involvement  includes  early  and  iterative  usability  and  human  performance  testing 
throughout  the  development  of  the  system  and  performance  testing  with  representative 
users  as  part  of  the  testing  and  evaluation  processes.  Subjective  feedback  from  the  user 
community  is  necessary,  but  objective  performance  testing  is  also  needed  to  determine 
the  true  impact  on  system  performance. 
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PARTICIPATION  IN  FUNCTION  ANALYSIS 

Since  function  decomposition  and  analysis  are  largely  performed  without  regard  to  the 
allocation  of  the  system’s  functions,  they  may  be  seen  as  areas  that  require  little  if  any 
human  engineering  participation.  The  human  engineer,  however,  can  assist  in  identifying 
functions  (such  as  life  support  of  display  capabilities)  that  must  be  included  because  of 
the  presence  of  humans  within  the  system.  Additionally,  much  of  the  human  engineer’s 
later  work  in  task  design  and  analysis  will  be  driven  by  the  results  of  the  function 
analysis.  Any  information  on  the  required  timing,  sequence,  or  interaction  of  functions 
can  be  highly  useful  in  the  design  of  human  tasks  and  jobs.  Without  human  engineering 
participation,  the  function  analysis  is  unlikely  to  contain  sufficient  details  for  functions  to 
be  allocated  to  humans,  adversely  impacting  later  designs  or  implementations. 


FUNCTION  ALLOCATION  DECISIONS 

Accurate  allocation  of  functions  between  humans  and  automation  requires  the 
consideration  of  the  capabilities  and  limitations  of  humans.  Therefore,  it  is  essential  that 
the  human  engineers  are  part  of  the  team.  The  earlier  this  participation  occurs,  the  better 
the  result  is  likely  to  be,  as  it  can  prevent  improper  design  decisions  that  are  costly  or 
impossible  to  change  at  a  later  date.  Such  allocation  decisions  need  to  be  an  explicit  part 
of  the  design  process  in  order  to  optimize  overall  system  performance.  Using  modeling 
techniques  and  sound  design  principles,  the  human  engineer  can  provide  reasonable 
estimations  of  what  functions  should  and  should  not  be  allocated  to  humans.  Making 
allocations  as  early  as  possible  helps  define  the  system  to  greater  detail  and  also  prevents 
these  allocations  from  being  made  to  the  wrong  system  component. 


COMPATIBILITY  OF  MODELS 

Modeling  and  simulation  techniques  allow  early  evaluation  of  system  designs,  including 
information  about  how  humans  interact  with  one  another  or  with  the  rest  of  the  system. 
Such  models  can  help  systems  engineers  optimize  the  human  performance  within  the 
system,  but  the  main  goal  should  be  to  set  human  performance  to  optimize  the 
performance  of  the  overall  system.  In  order  to  accomplish  this,  the  human  engineering 
models  need  to  be  compatible  with  other  models  used  in  the  design  of  the  system. 
Compatibility  can  include  transfer  of  static  data  between  models  as  well  as  interactive 
executable  models  and  simulations.  Model  compatibility  enables  accurate  models  of 
human  performance  and  modeling  of  how  human  performance  impacts  the  performance 
of  the  overall  system. 

For  future  complex  systems  to  perform  effectively,  humans  must  be  well  integrated  into 
the  design  process.  To  accomplish  integration,  the  systems  engineering  effort  must 
include  communication  with  and  integration  of  the  human  engineering  community.  Both 
communities  must  be  able  to  work  together  and  speak  a  common  language  in  order  to 
produce  systems  that  are  optimized  to  meet  the  needs  of  the  users  and  operators. 
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1  INTRODUCTION 


This  report  describes  significant  interactions  that  occur  between  human  engineers  and 
systems  engineers  during  system  development.  These  interactions  include  information 
that  must  be  shared,  decisions  that  must  be  made,  and  actions  or  decisions  that  require 
approval.  The  purpose  of  describing  these  interactions  is  to  provide  the  reader  with 
guidance  on  how  human  engineering  activities  may  be  better  integrated  with  an  overall 
system  development  or  systems  engineering  process.  It  is  intended  for  systems  engineers 
and  integrators  who  want  to  develop  systems  that  will  have  greater  consideration  o 
users  -  including  operators,  maintainers,  and  support  personnel.  It  is  also  intended  for 
human  engineers  and  human  factors  practitioners  to  help  them  have  a  greater  impact 
within  the  systems  engineering  process. 

The  interactions  were  identified  based  on  task  analyses,  documented  in  sets  of 
operational  sequence  diagrams  (OSDs),  of  both  systems  engineering  and  human 
engineering.  The  OSD  format  used  to  document  these  processes  is  a  modification  of  the 
methodology  and  symbology  of  traditional  OSDs.1  OSDs  are  typically  scenario-based 
and  used  for  detailed  human-machine  interface  analysis.  They  can  be  used  to  illustrate 
the  transfer  of  information  (input  and  output)  and  order  of  activities.  The  methodology 
used  in  this  instance  is  intended  to  support  higher-level  descriptions  of  system  operation 
and  processes.  For  this  use  of  the  modified  OSDs,  the  focus  was  on  documenting  the 
overall  capability  and  recommended  processes  rather  than  a  specific  scenario. 

The  systems  engineering  and  human  engineering  OSD  sets  were  documented  to  support 
the  development  of  the  ONR  (Office  of  Naval  Research)/SC-21  (Surface  Combatant  for 
the  21st  Century)  Science  &  Technology  Manning  Affordability  Initiative’s  Human 
Centered  Design  Environment  (HCDE).  The  HCDE  is  a  prototype  for  a  collaborative 
design  environment  that  supports  the  consideration  and  inclusion  of  human  operators  and 
users  throughout  the  design  process.  Sources  for  the  OSDs  included  standard  systems 
engineering  and  human  engineering  processes,  the  INCOSE  (International  Council  on 
Systems  Engineering)  Systems  Engineering  Handbook,  and  feedback  from  practicing 
systems  engineers  and  human  engineers.  The  OSDs  describe  the  process  m  terms  of  task 
units,  which  typically  include  associated  information  requirements,  decisions,  and 
products.  The  diagrams  for  systems  engineering  were  developed  first,  and  the  human 
engineering  diagrams  show  how  human  engineering  is  performed  in  the  overall  con^t 
of  systems  engineering  or  system  development.  Both  the  task  analysis  diagrams  and  the 
information  in  this  report  focus  on  human  engineering  activities,  although  other  human- 
system  integration  domains  such  as  manpower,  personnel,  training,  system  safety,  and 


i  Wallace,  D.F.;  Winters,  J.J.;  and  Lackie,  J.H.,  “An  Improved  Operational  Sequence  Diagram 
Methodology  for  Use  in  System  Development,”  in  Proceedings  of  the  Human  Factors  and  Ergonomics 
Society,  San  Diego,  CA,  2000,  pp.  6-505  —  6-508. 
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personnel  survivability  are  addressed  at  times.  The  identification  of  common  products, 
tasks,  and  information  requirements  permits  the  definition  of  interactions  between  the 
two  processes  (see  Appendix  A  for  URLs  for  the  systems  engineering  and  human 
engineering  process  task  analyses). 

The  interactions  are  intended  to  be  described  in  a  stand-alone  manner  that  does  not 
require  familiarity  with  any  specified  systems  engineering  or  human  engineering  process. 
However,  it  should  be  noted  that  the  perspective  taken  is  generally  from  the  systems 
engineer’s  point  of  view.  In  the  detailed  interaction  descriptions,  the  context  of  the 
interaction  within  systems  engineering  is  described  first,  followed  by  a  description  of  the 
manner  in  which  there  is  interaction  with  the  human  engineer.  The  systems  engineering 
process  information  is  included  for  context  purposes  only  and  is  not  intended  to  provide 
detailed  and  comprehensive  coverage  of  systems  engineering  activities. 

Throughout  the  descriptions,  the  terms  “systems  engineer”  and  “human  engineer”  are 
used.  Although  these  are  the  singular  forms,  the  terms  could  equally  be  pluralized  or 
described  as  engineering  teams.  For  the  purposes  of  this  report,  the  systems  engineer  is 
the  individual(s)  who  has  responsibility  for  the  design  of  the  system  as  a  whole. 
Typically,  the  systems  engineer’s  role  includes  programmatic  responsibilities,  but  the 
emphasis  in  this  report  is  on  the  technical  role.  The  systems  engineer  may  have  a  very 
active  role  in  the  definition  of  requirements  or  system  functions,  but  his  or  her 
responsibilities  change  during  the  physical  design  of  the  system.  At  this  point  in  the 
design  process  the  purpose  of  the  systems  engineer  is  that  of  an  integrator,  and  he  or  she 
is  responsible  for  combining  and  deconflicting  proposed  designs  submitted  by  engineers 
who  specialize  in  particular  disciplines  or  are  responsible  for  particular  subsystems.  The 
human  engineer  plays  one  of  these  roles,  specializing  in  job  and  task  design  and  the 
interaction  of  humans  with  one  another  and  with  the  rest  of  the  system.  His  or  her 
responsibility  covers  the  human  subsystems  within  the  system  to  be  designed.  The 
relationships  between  the  roles  described  in  this  report  are  illustrated  in  Figure  1-1. 
Although  each  of  the  relationships  shown  in  Figure  1-1  are  important,  this  report  focuses 
on  the  relationship  between  the  human  engineers  and  systems  engineers. 


Figure  1-1.  Context  of  Interactions  Between  the  Systems 
Engineer  and  the  Human  Engineer 
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Section  2  of  this  report  briefly  discusses  the  major  impact  areas  in  which  systems 
engineers  and  human  engineers  can  interact.  An  interaction  is  considered  significant  if  it 
has  a  relatively  large  impact  on  the  design  of  the  overall  system  or  if  its  omission  can 
lead  to  a  drastic  redesign  of  the  system.  An  interaction  could  also  be  significant  if  the 
proper  execution  of  the  development  process  requires  a  great  deal  of  iteration  or 
communication  between  the  systems  engineer  and  the  human  engineer.  The  major 
impact  areas  represent  abstractions  or  summations  of  recurring  or  important  themes  in  the 
interactions  that  follow.  The  key  issue  for  each  of  these  impact  areas  and  interactions  is 
that  integration  of  human  engineering  into  the  development  process  becomes  more 
effective  the  earlier  it  is  initiated. 

The  primary  portion  of  this  report.  Section  3,  describes  the  interactions  in  detail.  The  list 
of  interactions  has  been  grouped  into  eight  major  categories  that  are  roughly  grouped 
according  to  their  sequence  in  standard  systems  engineering  processes.  The  eight  phases 
discussed  in  this  report  include: 

1.  Mission  Analysis 

2.  Requirements  Analysis 

3.  Function  Analysis 

4.  Function  Allocation 

5.  Tt ask  Design  and  Analysis 

6.  Human  Interface  and  Team  Development 

7.  Performance,  Workload,  and  Training  Level  Estimation 

8.  User  and  Requirements  Review 

Figure  1  -2  provides  a  context  for  how  these  eight  categories  relate  to  different  top-level 
stages  of  standard  systems  engineering  processes.  In  reviewing  the  contents  of  Section  3, 
it  may  be  advantageous  to  refer  back  to  Figure  1  -2  to  enable  greater  understanding  o 
how  each  interaction  fits  into  the  overall  process  framework.  The  description  of  each 
interaction  includes  listings  of  relevant  activities  within  different  documented  systems 
engineering  processes.  Listings  of  these  relationships  ordered  by  steps  within  the 
systems  engineering  processes  are  provided  in  Appendix  A.  The  documents  referenced 
include  the  following: 

•  IEEE  1220-1998,  the  Standard  for  Application  and  Management  of  the  Systems 
Engineering  Process; 

•  ANSI/EIA-632-1998,  Processes  for  Engineering  a  System; 

•  the  CMMI SE/SW  v  1 .02  capability  maturity  model;  and 

•  Department  of  Defense  Regulation  5000.2-R,  Mandatory  Procedures  for  Maior 
Defense  Acquisition  Programs  (MDAPs)  and  Maior  Automated  Information 
System  (MATS)  Acquisition  Programs,  June  2001. 

References  to  relevant  sections  of  the  systems  engineering  OSDs  produced  within  the 
HCDE  project  are  also  provided.  Additional  sources  of  information  are  listed  in 
Appendix  B. 
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Figure  1-2.  Relationship  Between  Interaction  Categories  and  the  Systems  Engineering  Process 
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2  MAJOR  IMPACT  AREAS 


Based  on  the  interactions  described  in  this  report,  four  major  impact  areas  for  human 
engineering  participation  have  been  identified. 

•  User  Involvement  and  Representation 

•  Participation  in  Function  Analysis 

•  Function  Allocation  Decisions 

•  Compatibility  of  Models 

These  interactions  are  not  meant  to  represent  the  bulk  of  the  human  engineer’s  work;  they 
are  intended  to  represent  the  most  important  ways  in  which  the  human  engineer  mus 
interact  with  the  systems  engineer  and  other  designers.  The  interactions  do  not 
necessarily  represent  what  is  currently  planned  or  carried  out  m  system  development,  b 
they  instead  signify  key  interactions  through  which  human  engineering  can  be  better 
integrated  within  systems  engineering.  Although  the  level  of  human  engineering 
participation  will  vary  with  different  design  stages  (e.g.,  concept  definition  versus 
detailed  design),  the  human  engineering  team  should  have  end-to-end  involvement  m  the 
system  development  process.  Initiation  of  human  engineenng  activities  only  late  in  the 
process  makes  such  analyses  largely  irrelevant  due  to  the  fact  that  time  and  resources  w 
not  be  available  to  make  anything  but  superficial  design  changes.  User-inclusive 
reauirements  must  be  written  in  order  to  plan  and  conduct  analyses  that  account  for 
human  performance  and  limitations  within  the  context  of  the  total  system  Such  ana  yses 
must  be  conducted  and  evaluated  by  those  who  understand  how  to  translate  them  into 
effective  design  solutions. 

2.1  USER  INVOLVEMENT  AND  REPRESENTATION 

Bv  far  the  most  critical  area  in  which  human  engineering  activities  should  be 
incorporated  into  the  design  process  is  the  area  of  user  involvement  and  representation. 
The  human  engineer  needs  to  both  facilitate  feedback  from  users  on  concepts  and  designs 
as  well  as  conduct  user  testing.  The  scope  of  this  impact  area  ranges  from i  the  creat ion ^f 
accurate  and  relevant  user-centered  scenarios  to  solicitation  of  subjective  feedback  from 
users  to  analysis  of  the  results  of  objective  human  performance  testing. 

The  human  engineer  is  often  required  to  extend  previous  scenarios  or  build  new  scenarios 
in  order  to  identify  and  provide  details  about  how  the  operators  and  users  will  interact 
with  the  rest  of  the  system.  Different  phases  or  modes  of  operation  can  be  described,  and 
scenarios  may  cover  typical  conditions,  degraded  conditions,  emergency  conditions,  and 
woTcase  situations.  While  many  scenarios  used  in  system  development  or  testing  may 
only  cover  conditions  and  events  external  to  the  system  or  actions  at  the  total-system 
level,  the  human  engineer  is  more  interested  in  scenarios  that  describe  how  the  system 
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will  respond  and  operate  from  the  user’s  point  of  view.  Scenarios  that  describe  only 
events  and  conditions  external  to  the  system  can  be  expanded  to  include  system  operation 
and  functionality  from  the  perspective  of  the  user.  For  example,  a  scenario  that  describes 
takeoff  and  cruising  at  2500  feet  at  150  knots  can  be  expanded  to  include  user  tasks  of 
reviewing  map  and  weather  information  to  select  the  best  course  to  the  destination. 

Scenarios  of  system  use  are  used  to  build  task  and  job  analyses  for  the  operators  and 
users  and  also  to  test  designs  and  procedures.  Since  these  scenarios  are  written  from  the 
perspective  of  the  users  and  operators,  they  can  be  excellent  vehicles  for  soliciting 
feedback  during  user  reviews  or  as  the  basis  for  a  user  task  model  that  describes  user 
tasks,  task  sequences,  and  task  interactions.  Scenarios  can  be  simply  represented  as 
written  descriptions  or  storyboard  sequences;  therefore,  they  can  be  used  in  the  early 
stages  of  system  development.  The  detailed  inner  workings  of  the  hardware  and  software 
do  not  need  to  be  defined  because  such  details  are  less  relevant  from  the  user  s 
perspective.  Representative  users  typically  are  able  to  provide  better  and  more  detailed 
feedback  from  a  descriptive  scenario  than  from  a  list  of  requirements  or  functional 
description.  Regular  user  review  throughout  the  development  process  provides  a  level  of 
presence  to  the  user,  leading  to  a  more  detailed  understanding  of  system  operation  and 
greater  feedback  on  the  design  to  the  human  engineer  and  the  rest  of  the  design  team. 
Regular  user  reviews  also  provide  user  buy-in  when  the  final  system  is  delivered. 

The  review  of  user-centered  scenarios  with  representative  users  or  other  appropriate 
individuals  can  provide  feedback  on  the  system’s  physical  design,  functional  capabilities, 
or  even  performance  requirements.  Without  this  sort  of  review,  the  systems  engineer  can 
only  assume  that  the  system’s  requirements  are  compatible  with  the  needs  and  limitations 
of  the  users  or  operators.  Such  reviews  are  a  critical  aspect  of  the  validation  of 
requirements  and  designs. 

Due  to  training,  experience,  and  related  responsibilities,  the  human  engineer  is  typically 
the  designer  who  is  best  suited  to  coordinate  user  reviews  of  scenarios  and  system 
designs.  To  allow  scenarios  to  be  used  in  this  way,  the  human  engineer  must  have 
scenarios  that  accurately  represent  the  interaction  of  personnel  with  the  rest  of  the  system. 
The  human  engineer  must  also  be  prepared  to  collect  feedback  on  issues  such  as 
requirements  and  system  functions  in  addition  to  control  and  display  configurations. 
Understanding  of  these  issues,  such  as  how  the  system  is  intended  to  work  and  the 
proposed  tasks  for  users  and  operators,  is  essential  to  comprehend  the  human  roles  in  the 
overall  operation,  maintenance,  and  use  of  the  system.  With  adequate  interaction 
between  the  human  engineer  and  the  systems  engineer,  scenarios  and  user  reviews  can 
allow  for  early  and  rapid  feedback  on  system  requirements,  functions,  and  designs. 

In  addition  to  review  of  user-centered  scenarios,  effective  user  review  will  also 
incorporate  early  and  frequent  usability  and  human  performance  testing.  Static  versions 
of  the  user  interface  can  be  used  in  conjunction  with  usage  scenarios  to  obtain  feedback 
before  working  prototypes  are  constructed.  User  review  is  not  complete  until 
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representative  users  have  been  employed  in  performance  testing  to  ensure  that  the 
operational  system  will  perform  and  interact  with  the  users  and  operators  as  anticipated. 


2.2  PARTICIPATION  IN  FUNCTION  ANALYSIS 

Since  the  decomposition  of  functions  and  definition  of  the  functional  architecture  is 
largely  performed  without  regard  to  the  allocation  of  the  system’s  functions^.!  may  be 
seen  as  an  area  that  requires  little  if  any  human  engineering  participation.  There  are 
however,  two  distinct  reasons  for  human  engineering  participation  that  can  reduce  the 
potential  for  having  to  change  the  function  analysis  at  a  later  date.  Fnxt,  the  human 
engineer  can  assist  in  identifying  implied  functions  that  must  be  included  because  of  the 
presence  of  humans  within  the  system.  Some  functions,  such  as  life-support  or 
communications,  may  be  required  regardless  of  the  humans’  assigned  responsibilities. 
Other  functions  will  become  apparent  once  some  preliminary  allocations  are  made, 
including  those  allocations  that  may  be  assumed  from  the  system  s  initial  concept  of, 
operations  Second,  much  of  the  human  engineer’s  later  work  in  function  allocation  and 
in  task  design  and  analysis  will  be  driven  by  the  results  of  the  function  analysis 
Information  requirements,  performance  requirements,  and  decision  requirements  need  to 
be  defined  to  facilitate  function  allocation.  Any  information  on  the  timing,  sequence,  or 
interaction  of  functions  can  be  highly  useful  in  the  design  of  human  tasks  and  jobs. 
Timing  and  overlap  of  tasks  will  influence  workload,  and  unpredictable  task  sequencing 
can  greatly  decrease  cognitive  performance,  such  as  accuracy  of  decisions  or  time  to 
review  and  understand  information.  Without  human  engineering  participation,  the 
function  analysis  is  likely  to  contain  insufficient  details  for  functions  and  subfunctions  to 
be  optimally  allocated  to  humans.  The  human  engineer  is  then  left  to  make  potentially 
inconect  assumptions  about  the  information  or  to  continue  the  function  analysis  through 
further  decomposition  or  definition  of  the  functions. 


2.3  FUNCTION  ALLOCATION  DECISIONS 


Since  accurate  allocation  of  functions  to  system  elements  requires  consideration  of  the 
capabilities  and  limitations  of  humans,  the  participation  of  the  human  engineer  is 
essential.  Function  allocation  will  be  performed  for  all  systems  developed,  either 
explicitly  or  by  default.  The  key  issue  is  whether  or  not  the  allocation  process  attempts  to 
determine  the  best  combination  of  humans  and  automation  to  accomplish  the  functions. 
The  human  engineer  can  provide  reasonable  estimations  of  what  functions  or  portions  o 
functions  should  and  should  not  be  allocated  to  humans.  Until  functions  and 
subfunctions  have  been  defined  to  significant  detail,  most  functions  will  be  allocated  to 
“combinations”  and  not  “fully  manual”  or  “fully  automated,”  but  the  human  engineer  can 
help  to  describe  and  model  how  the  human  and  technology  can  interact  to  accomplish  the 

function  optimally. 

The  systems  engineer  and  other  participants  in  the  function  allocation  process  are  likely 
to  have  a  good  idea  of  the  capabilities  and  limitations  of  humans  in  general,  but  the 
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human  engineer  is  likely  to  know  more  about  or  have  better  tools  to  estimate  the  specific 
capabilities  and  limitations  of  the  intended  users.  The  earlier  this  participation  occurs, 
the  better  the  result  is  likely  to  be,  as  it  can  prevent  improper  design  decisions  that  are 
costly  or  impossible  to  change  at  a  later  date.  The  human  engineer  can  assist  in 
identifying  functions  or  portions  of  functions  that  are  required  to  have  a  particular 
allocation.  Reasons  for  such  decisions  include  functions  that  are  absolutely  beyond  the 
capabilities  of  the  anticipated  users,  assumptions  made  as  part  of  the  system’s  initial 
concept,  and  grouping  of  functions  that  will  benefit  job  design.  Making  these  mandated 
or  intuitively  obvious  allocations  as  early  as  possible  helps  define  the  system  in  greater 
detail,  narrows  the  design  space,  and  also  prevents  these  allocations  from  being  made  to 
the  wrong  system  element  or  component. 


2.4  COMPATIBILITY  OF  MODELS 

Proposed  designs  of  systems,  subsystems,  or  components  can  be  evaluated  before  the 
system  is  constructed  through  modeling.  Although  differing  in  scope  or  detail  when 
compared  to  models  of  other  disciplines,  human  engineering  models  provide  useful 
information  about  how  humans  interact  with  one  another  and  with  the  rest  of  the  system. 
Such  models  can  help  the  human  engineer  optimize  the  performance  of  humans  within 
the  system.  Task  network  models  can  predict  time  or  accuracy  of  task  completion, 
anthropometric  models  can  be  used  to  determine  reach  limits  or  lines  of  sight  over 
consoles,  and  cognitive  models  can  estimate  attentional  demand  or  predict  operator 
behaviors. 


The  main  goal  of  the  human  engineer,  however,  should  be  to  determine  the  required 
performance  of  the  human  in  order  to  optimize  the  performance  of  the  overall  system.  To 
accomplish  this,  the  human  engineering  models  need  to  be  compatible  with  other  models 
used  in  the  design  of  the  system.  Compatibility  can  permit  the  interoperability  of  human 
engineering  models  with  models  built  by  other  specialty  engineering  groups,  and  it  may 
also  allow  human  engineers  to  extend  existing  models.  Without  such  compatibility,  the 
human  engineering  models  will  not  include  an  accurate  representation  of  the  system  s 
hardware  and  software.  Model  compatibility  facilitates  accurate  models  of  human 
performance  and  human  performance  impacts  on  the  performance  of  the  overall  system. 
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3  INTERACTION  DETAILS 

This  section  of  the  paper  outlines  all  of  the  systems  and  human  engineering  interactions 
uncovered  from  task  analyses  of  the  two  processes.  These  descnptions  are  listed  in  an 
order  compatible  with  their  occurrence  in  systems  engineenng  processes.  Each 
interaction  begins  with  contextual  information  to  characterize  the  design  process  at  the 
time  of  the  interaction.  Additional  detailed  information  about  ^interaction follows,  as 
well  as  the  implications  for  the  process.  Finally,  references  to  IEEE  1220-1998 
ANSI/EIA-632-1998,  the  Engineering  process  area  category  of  CMMI-SE/bW  v  l.UA 
DoD  5000.2-R,  and  the  Systems  Engineering  OSDs  (SE  OSDs)  are  provided. 

3.1  MISSION  ANALYSIS 

The  mission  analysis  phase  of  system  development  determines  required  system 
capabilities  and  the  system’s  mission  or  purpose.  Dunng  this  phase,  the  boundaries  o 
the  system  need  to  be  identified,  as  do  the  interactions  of  the  system  with  its  environment 
and  with  other  external  systems.  Scenarios  or  mission  profiles  are  also  created.  Pot^tia 
inputs  and  products  of  human  engineering  activities  dunng  Mission  Analysis  are  listed  in 

Table  3-1. 

Although  human  engineering  does  not  drive  mission  analysis,  it  is  still  critical  due  to  its 
influence  in  determining  human  roles  within  the  defined  system  a—  to  the  cost  ot 
significant  changes  at  a  later  date.  Problems  that  result  from  inadequate  involvement 


Table  3-1.  Human  Engineering  Inputs  and 

Inputs 

•  Requests  for  Proposals  (RFPs) 

•  Planning  documents 

•  Systems  requirements  documents 

•  Subject  Matter  Expert  inputs 

•  Concept  of  operations 

•  Mission  Needs  Statement  (MNS) 

•  Lessons  learned 


Products  in  Mission  Analysis 


Products 


Descriptions  of  situations  or  events  that  will 
confront  operators  and  maintainers,  i.e., 
possible  scenarios 

List  of  system  operational  and  maintenance 
requirements 

Descriptions  of  assumed  operations 

List  of  operations  that  appear  feasible 

Possible  operations  &  maintenance  thresholds 

Environmental  factors  possibly  affecting 

system  performance 

List  of  possible  failures  and  effects 

Human  roles 

Operator  expectations 
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include  deficiencies  in  scenarios  and  environmental  descriptions.  None  of  the  system 
scenarios  may  include  events  from  the  user  point  of  view,  and  they  may  not  cover  a 
sufficient  range  of  events  or  conditions  to  adequately  cover  human  involvement. 
Similarly,  the  full  range  of  environmental  conditions  needs  to  be  defined  to  enable  the 
identification  of  the  ramifications  of  environmental  impact  on  system  performance. 


3.1.1  Selection  of  Comparison  Systems 

A  frequently  used  approach  in  system  development  is  comparison  of  the  system  under 
design  to  predecessor  systems.  While  this  technique  is  more  straightforward  for 
evolutionary  designs,  it  may  still  be  employed  for  systems  that  have  no  direct 
predecessor.  All  or  part  of  the  current  system  may  be  compared  to  all  or  part  of  some 
previous  system  that  served  a  similar  function,  had  a  similar  goal,  or  included  similar 
components.  This  may  be  a  formal  process  in  which  the  performance  and  attributes  of 
the  predecessor  system  are  quantified  and  set  as  a  baseline  upon  which  the  new  system 
must  improve.  It  could  also  include  a  review  of  lessons  learned  from  previous  systems. 
Although  it  may  be  informal  or  even  unintentional,  some  comparison  is  performed  any 
time  the  developers  have  prior  experience  with  the  development  or  use  of  similar 
systems.  Samples  of  potential  inputs  to  this  activity  and  products  from  the  comparison 
with  other  systems  are  listed  in  Table  3-2. 

Within  the  human  engineering  process,  previously  designed  or  built  systems  or 
subsystems  are  selected  for  comparison  with  the  system  under  design.  The  system  under 
development  may  have  multiple  comparison  systems  or  a  variety  of  comparison 


Table  3-2.  Human  Engineering  Inputs  and  Products  in  Selection  of  Comparison  Systems 


Inputs 

•  Data  on  operability  and  usability  of 
comparison  system 

•  Maintainability  of  comparison  system 

•  Staffing  data  on  comparison  system 

•  Knowledge,  skills,  and  abilities  (KSAs) 
required  of  users  of  comparison  system 

•  Personnel  opinions  and  problems 
encountered  using  comparison  system 

•  Training  required  for  operators  to  reach 
target  proficiency  on  comparison  system 

•  Historical  data  on  errors,  including 
design  errors  impacting  human 
performance  in  comparison  system 

•  Workload  analysis  of  users  of 
comparison  system 

•  Lessons  learned 


Products 

•  Critical  incident  analyses 

•  Identification  of  environmental  factors  that 
may  affect  personnel 

•  Preliminary  predictions  of  workload  and 
stress  levels 

•  Predicted  knowledge,  skills,  and  abilities 
(KSAs)  required  and  their  impact  on  staffing, 
training,  and  design 

•  Predicted  staffing 

•  Identification  of  potential  problem  areas 
relating  to  operation  and  maintenance  for 
focus  in  the  new  design 

•  Predictions  relating  to  allocation  differences 
between  old  and  new  system 
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subsystems  from  different  pre-existing  systems.  The  human  engineering  practitioner  may 
observe  or  otherwise  analyze  the  performance  of  the  comparison  systems  to  establish 
design  goals  or  performance  requirements.  Among  the  different  types  of  data  that  may 
be  collected  are  historical  data,  observational  data,  user  data  or  feedback,  and  data  from 
experimental  prototypes.  Information  on  past  performance  of  multiple  comparison 
systems  may  be  used  to  select  or  narrow  options  for  designs. 

While  the  comparison  systems  must  be  similar  to  the  current  system  in  either  mission  or 
implementation,  a  system  that  is  useful  to  the  human  engineer  due  to  details  of  the 
human-machine  interface  may  not  be  useful  at  the  overall  system  integration  level.  The 
human  engineer,  however,  will  be  required  to  address  systems  selected  by  the  systems 
engineers  or  others  as  a  baseline  for  comparison.  The  comparison  could  be  based  on 
similar  missions,  requirements,  functions,  tasks,  users,  or  other  factors.  Systems  or 
subsystems  that  the  systems  engineer  considers  relevant  for  the  human  engineer  should 
be  assessed  by  the  human  engineer  to  confirm  their  similarity  and  applicability  to  the 
system  under  design.  The  human  engineer  may  find  information  on  comparison  systems 
selected  by  the  systems  engineers  to  be  very  useful  in  providing  context  or  benchmarks 
for  human  performance  measures.  The  human  engineer  may  want  to  seek  approval  or 
concurrence  from  the  systems  engineer  for  the  use  of  some  comparison  systems  identified 
for  system  components  under  human  engineering  design  responsibility.  An  ear  y 
identification  of  comparison  systems  will  allow  the  subsequent  recommendations  to  have 
a  more  effective  influence  on  design  decisions. 

IEEE  1220-1998:  6.1.2  -  Define  project  and  enterprise  constraints 

6.1.3-  Define  external  constraints 
EIA-632:  Requirement  4  -  Process  Implementation  Strategy 

Requirement  13  -  Information  Dissemination 
SE/SW  CMM:  Requirements  Management,  SP  1.1-1  —  Obtain  an  Understanding  of 

Requirements  . 

Technical  Solution,  SP  1.1-1  -  Develop  Alternative  Solutions  and  Selection 

Criteria 

DoD  5000.2-R:  C5.2  -  Systems  Engineering 

SE  OSDs:  SE1 10-  Define  and  Assess  Operational  Environment 


3.1.2  System  Use  Scenarios 

Products  such  as  system  scenarios,  design  reference  missions,  and  mission  profiles  or 
timelines  are  used  by  a  variety  of  disciplines  during  system  design.  Information  from 
these  sources  can  be  used  to  identify  required  interactions  with  external  systems, 
determine  functional  requirements  for  a  system,  and  establish  performance  requirements 
for  interaction  with  external  systems.  Once  designs  are  complete,  such  scenanos  and 
timelines  may  be  used  to  evaluate  or  validate  system  design  options.  Potential  human 
engineering  inputs  and  products  in  system  use  scenarios  are  shown  in  Table  3-3. 
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Table  3-3.  Human  Engineering  Inputs  and  Products  in  System  Use  Scenarios 


Inputs 

Products 

• 

System  scenarios 

• 

Estimates  or  verifications  of  staffing 

• 

Design  Reference  Missions  (DRMs) 

requirements 

• 

Mission  profiles  and  timelines 

• 

Estimates  or  verifications  of  workload  and 

• 

Subject  Matter  Expert  inputs 

stress  levels 

• 

Concept  of  operations 

• 

Evaluation  and  ranking  of  predicted 
knowledge,  skills,  and  abilities  (KSAs) 
required  and  their  impact  on  staffing, 
training,  and  design 

• 

Evaluation  of  the  desirability  and 
consequences  of  allocation  different  from 
comparison  systems 

• 

Identification  of  potential  problem  areas 
relating  to  operation  and  maintenance  for 
focus  in  the  new  design 

In  order  to  adequately  account  for  the  users  or  operators  of  the  system  under 
development,  some  scenarios  must  be  defined  from  the  user  or  operator  perspective. 
System  use  scenarios  describe,  from  the  user’s  point  of  view,  detailed  events  of  the 
system  mission,  including  identification  of  mission  phases,  mission  time  scale,  and  events 
external  to  (and  their  interactions  with)  the  system.  Scenarios  selected  by  the  human 
engineer  should  address  cognitive  and  physical  tasks  and  should  emphasize  impact  on 
human  performance,  potential  environmental  effects,  and  safety.  Additionally,  they  must 
be  representative  of  the  expected  operating  environment  and  threats  to  the  system  or 
mission.  Scenarios  of  this  type  are  necessary  to  perform  job  or  task  design,  and  they  can 
be  used  to  determine  requirements  for  human-system  interfaces.  Scenarios  from  the 
user’s  perspective  are  powerful  tools  for  eliciting  user  or  subject  matter  expert  feedback 
early  in  the  design  process.  If  use  case  models  or  user  models  are  being  developed,  user- 
centered  scenarios  can  assist  in  identifying  user  tasks,  task  sequences,  and  task 
interactions. 

System  use  scenarios  defined  by  the  human  engineer  will  often  be  extensions  or  subsets 
of  scenarios  developed  or  approved  by  the  systems  engineers,  as  would  scenarios  used 
within  other  design  domains.  Human  engineers  and  other  designs  should  use  the  same 
scenarios,  with  each  group  decomposing  them  to  the  appropriate  levels  of  detail.  The 
definition  of  system  use  scenarios  will  typically  require  assumptions  on  the  part  of  the 
human  engineer  that  further  define  the  system.  These  scenarios,  therefore,  should  be 
either  approved  or  at  least  reviewed  by  the  systems  engineers  and  coordinated  across 
design  domains.  The  human  engineer  must  ensure  that  system  use  scenarios  accurately 
reflect  a  potential  or  achievable  design  and  are  consistent  with  other  scenarios  used  in 
system  development.  Interaction  in  creating  and  refining  these  scenarios  provides  the 
systems  engineering  with  scenarios  that  are  more  complete  and  provides  the  human 
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engineer  with  a  better  context  for  system  operations.  Scenarios  must  provide  conditions 
that  realistically  tax  human  capabilities. 

The  development  and  subsequent  use  of  system  use  scenarios  is  critical  for  the  human 
engineer.  Without  valid  scenarios  to  use  in  task  design  or  defining  user  test  situations,  it 
will  be  difficult  -  if  not  impossible  -  to  account  for  users  and  operators  in  the  design 
process.  As  scenarios  extend  assumptions  about  system  design,  those  assumptions  must 
be  verified  or  accepted  by  other  disciplines.  Collaboration  with  the  systems  engineer  in 
scenario  development  will  increase  the  probability  that  suggestions  from  user  or  subject 
matter  expert  reviewers  will  be  accepted.  Tasks  that  are  specific  to  the  use  of  interfaces 
or  team  interaction  will  have  to  be  added  to  system  use  scenarios,  and  these  extensions 
will  also  need  to  be  verified  with  the  systems  engineer  and  other  design  disciplines. 

IEEE  1220-1998:  6.1.4  —  Define  operational  scenarios 

6.1.12 -Define  modes  of  operations 
EIA-632:  Requirement  4  -  Process  Implementation  Strategy 

Requirement  16  —  System  Technical  Requirements 
Requirement  24  -  Risk  Analysis 

SE/SW  CMM:  Requirements  Development,  SP  1.1-1  —  Collect  Stakeholder  Needs 

Requirements  Development,  SP  1.1-2  —  Elicit  Needs 
Requirements  Development,  SP  1.2-1  -  Transform  Stakeholder  Needs, 
Expectations,  Constraints,  and  Interfaces  into  Customer  Requirements 
Requirements  Development,  SP  3.1-1  -  Establish  Operational  Concepts  and 
Scenarios 

Requirements  Development,  SP  3.5-2  -  Validate  Requirements  with 
Comprehensive  Methods 

Technical  Solution,  SP  1.1-2  -  Develop  Detailed  Alternative  Solutions  and 
Selection  Criteria 

Technical  Solution,  SP  1.2-2  -  Evolve  Operational  Concepts  and  Scenarios 
Technical  Solution,  SP  2.2-3  -  Establish  a  Complete  Technical  Data  Package 
Verification,  SP  1.2-2  -  Establish  the  Verification  Environment 
Validation,  SP  1.2-2  -  Establish  the  Validation  Environment 
DoD  5000.2-R:  C2.8.5.5  -  Human  Factors  Engineering 

C3.2.3.2  -  T&E  Guidelines 
C5. 2.3.5. 2.6  -  M&S  Support  ofSBA 
C5.2.3.5.9.1  -Human  Factors  Engineering  (HFE) 

SE  OSDs:  SE1 10-  Define  and  Assess  Operational  Environment 


3.1.3  User  Environment  Characteristics  and  Effects 

The  design  of  the  system  must  account  for  the  environmental  conditions  under  which  the 
system  will  be  employed.  A  wide  range  of  environments  is  possible,  and  all  relevant 
factors  should  be  considered.  Natural  conditions  such  as  weather,  topology,  time  of  day, 
and  lighting  conditions  are  of  interest,  as  are  conditions  such  as  noise,  vibration,  and  heat 
induced  by  the  operation  of  the  system.  Threat  conditions  such  as  chemical  or  biological 
agents  and  use  of  lasers  should  also  be  identified.  Once  the  conditions  are  identified,  the 
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effects  of  those  conditions  and  any  resultant  design  constraints  should  be  ascertained. 
Potential  inputs  and  products  for  these  activities  are  shown  in  Table  3-4. 


Table  3-4.  Human  Engineering  Inputs  and  Products  in  User  Environment  Characteristics  and  Effects 


Inputs 

•  Natural  environmental  conditions 
(weather,  topology,  time  of  day) 

•  Induced  environmental  conditions 
(lighting,  noise,  vibration,  and  system 
induced  heat) 

•  System  scenarios 

•  Design  Reference  Missions  (DRMs) 

•  Mission  profiles  and  timelines 

•  Concept  of  operations 

•  Required  Operational  Capability/ 
Projected  Operational  Environment 
(ROC/POE) 


Products 

•  Effects  of  predicted  natural  environmental 
conditions 

•  Design  constraints  resulting  from  natural 
conditions 

•  Effects  of  predicted  system  conditions 

•  Design  constraints  resulting  from  system 
conditions 

•  Strategies  to  mitigate  environmental  impact 
on  users 

•  User  performance-shaping  events  and  impact 
of  those  events 


The  human  engineer  will  need  to  assess  the  environmental  conditions  catalogued  by  the 
systems  engineers  and  determine  whether  or  not  all  conditions  that  significantly  affect 
humans  have  been  identified.  Operators  and  users  must  be  shielded  entirely  from  some 
environmental  characteristics  and  other  characteristics  will  influence  their  performance. 
The  human  engineer  will  need  to  quantify  the  effects  of  environmental  characteristics  on 
human  performance  and  work  together  with  the  systems  engineers  and  other  design 
disciplines  to  make  design  decisions.  In  some  cases,  the  human  engineer  will  need  to 
determine  how  to  mitigate,  eliminate,  or  compensate  for  environmental  effects.  As  more 
of  the  system’s  physical  design  is  completed,  additional  induced  environmental  factors, 
such  as  vibration  and  noise,  will  become  apparent  or  better  defined.  The  human  engineer 
must  therefore  iteratively  review  or  be  continually  involved  in  development  of  system 
designs  to  continue  to  identify  induced  factors  and  determine  how  external  environmental 
factors  may  affect  humans.  In  some  cases,  the  human  engineer  will  make  assumptions 
about  environmental  factors  that  are  present  and  will  need  to  clarify  or  present  those 
assumptions  to  the  systems  engineers.  High  levels  of  noise  in  a  control  center,  for 
example,  will  impair  verbal  communications  unless  noise-attenuating  communications 
headsets  are  used. 

Once  the  effects  of  environmental  factors  have  been  assessed,  it  must  be  determined 
whether  or  not  desired  levels  of  system  and  human  performance  can  be  achieved.  Any 
performance  effects  of  the  environment  will  need  to  be  included  in  system  or  component 
models  and  simulations.  The  systems  engineers  and  other  designers  will  need  to  know 
about  such  performance  degradations,  and  will  also  need  to  be  given  specific 
requirements  for  and  performance  impact  of  equipment  to  mitigate  or  inhibit 
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environmental  effects  that  have  been  identified.  Approaches  to  mitigate  environmental 
effects  include  breathing  or  life  support  apparatuses,  vibration  damping,  noise 
cancellation,  hearing  protection,  protective  clothing,  lighting,  and  operator  exposure  or 

duty  limits. 

IEEE  1220-1998:  6.1.8  -  Define  utilization  environments 

EIA-632:  Requirement  16  -  System  Technical  Requirements 

Requirement  24  —  Risk  Analysis 

SE/SW  CMM:  Requirements  Development,  SP  3.5-1  -  Validate  Requirements 

Technical  Solution,  SP  1.2-2 -Evolve  Operational  Concepts  and  Scenarios 
Product  Integration,  SP  1.2-2  -  Establish  the  Product  Integration  Environment 
Verification,  SP  1.1-1  -  Establish  a  Verification  Strategy 
Verification,  SP  1.2-2  -  Establish  the  Verification  Environment 
Validation,  SP  1.1-1  -  Establish  a  Validation  Strategy 
Validation,  SP  1.2-2  -  Establish  the  Validation  Environment 
DoD  5000.2-R:  C2.8.5.4  —  Personnel  Survivability  and  Habitability 

C2.8.5.5  -  Human  Factors  Engineering 

C2. 8.6  -  Environment,  Safety,  and  Occupational  Health  (ESOH) 
Considerations 

C5.2.3.5.9.1  -  Human  Factors  Engineering  (HFE) 

C5. 2.3.5. 9.2  -  Habitability  and  Personnel  Survivability 

C5.2.3.5. 10  -  Environment,  Safety,  and  Occupational  Health  (ESOH) 

SE  OSDs:  SE1 10-  Define  and  Assess  Operational  Environment 


3.2  REQUIREMENTS  ANALYSIS 

During  requirements  analysis,  source  requirements  are  identified,  clarified,  and 
prioritized.  Requirements  are  assessed  for  consistency,  coherence,  and  completeness. 
The  requirements  are  broken  down  or  decomposed  into  greater  detail.  Each  lower-level 
requirement  must  be  traceable  to  higher-level  requirements.  As  the  requirements  are 
defined  in  greater  detail,  they  will  become  more  specific  to  the  planned  implementation 
of  the  system,  and  the  involvement  of  designers  within  different  disciplines  becomes 
necessary.  Examples  of  inputs  and  outputs  of  human  engineering  activities  related  to 
Requirements  Analysis  are  listed  in  Table  3-5. 

Human  engineering  involvement  in  requirements  analysis  activities  is  vital  since  human 
engineering-related  criteria  are  unlikely  to  be  assessed  without  the  prior  definition  of 
appropriate  requirements.  Unfortunately,  definition  of  requirements  pertaining  to  t  e 
user  population  and  human-system  integration  is  at  times  deferred  until  later  in  the 
development  process.  Human  engineering  requirements  may  also  be  defined  at  an 
insufficient  level  of  detail,  stating,  for  example,  that  the  system  “shall  be  usable.  Such 
vague  requirements  alone  provide  no  guidance  for  design  decisions,  nor  do  they  permit 
human  engineering  design  evaluations  to  carry  any  weight  in  tradeoff  decisions.  Due  to 
their  tremendous  impact  on  the  overall  system  life  cycle,  requirements  relating  to  bot 
training  and  selection  must  also  be  addressed  at  this  stage  of  the  development  process. 
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Defining  training  requirements  enables  the  anticipated  amount  of  training  to  be  used  as  a 
factor  in  design  tradeoffs. 


Table  3-5.  Human  Engineering  Inputs  and  Products  in  Requirements  Analysis _ 

Products 

•  Anticipated  knowledge,  skills,  and  abilities 


Inputs 

•  Source  requirements 

•  Explicit  constraints 

•  Requirements  of  comparison  systems 

•  Higher-level  HCI  style  guide(s) 

•  Human  capabilities  and  limitations 

•  System  capabilities  and  limitations 


(KSAs)  of  users 
Decomposed  requirements 
Implicit  constraints 

Human  performance  requirements  such  as 
time  allowed  and  accuracies 
Human  engineering  design  requirements 
Hardware  and  software  requirements  to 
support  operators  and  maintainers 
Decision  and  Information  Requirements 
System-specific  HCI  style  guide 
Information  Exchange  Requirements  (IERs) 


Definition  of  human  engineering  requirements  independent  of  system-wide  requirements 
also  degrades  their  ability  to  positively  impact  designs.  Human  performance 
requirements  must  be  related  to  system-level  or  other  engineering  requirements  in  order 
to  develop  optimal  designs.  While  it  is  certainly  simpler  to  define  and  test  human 
engineering  requirements  separately,  the  impact  of  human  engineering  requirements  and 
design  decisions  on  overall  system  performance  needs  to  be  addressed. 


3.2.1  Human  Engineering  Constraints 

Constraints  are  implied  requirements  that  restrict  the  design  of  a  system.  They  are 
imposed  by  external  limitations  and  will  impact  specifications.  Many  more  design 
constraints  will  be  involved  in  the  development  of  systems  that  retain  major  components 
of  previous  systems.  If  more  constraints  are  known  early  in  the  design  process,  it  is 
easier  to  narrow  the  design  space  for  the  system. 

Constraints  that  impact  the  work  of  the  systems  engineer  are  likely  to  impact  the  work  of 
the  human  engineer  as  well.  To  ensure  that  all  participants  are  aware  of  the  restrictions, 
overall  constraints  of  the  system  should  be  documented.  These  should  include 
constraints  that  come  from  inherent  capabilities  and  limitations  of  humans.  For  example, 
basic  human  physiology  limits  the  amount  of  g-force  that  a  piloted  aircraft  can  safely 
withstand,  and  the  limits  of  working  memory  restrict  the  number  of  options  that  can  be 
evaluated  at  one  time.  Additional  constraints  may  arise  due  to  design  decisions  or 
analyses  by  the  human  engineer.  More  specific  constraints  will  arise  in  different  user 
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copulations  due  to  the  specific  knowledge  bases  and  skill  sets  available.  Once  the 
characteristics  of  the  user  population  become  more  certain,  more  constraints  may  become 
apparent.  As  they  arise,  these  constraints  must  be  identified  and  passed  on  to  other 
design  disciplines.  In  some  cases,  constraints  from  different  disciplines  must  be 
developed  and  documented  in  parallel,  requiring  collaboration  between  design 

disciplines. 

IEEE  1220-1998:  6.1.2-  Define  project  and  enterprise  constraints 

6.1.3  -  Define  external  constraints 
6.1.15  -  Define  human  factors 
EIA-632:  Requirement  5  -  Technical  Effort  Definition 

Requirement  14  —  Acquirer  Requirements 
Requirement  15  -  Other  Stakeholder  Requirements 
Requirement  16  —  System  Technical  Requirements 

Requirement  19 -Specified  Requirements  ... 

SE/SW  CMM:  Requirements  Management,  SP  1.1-1  -  Obtain  an  Understanding  oj 

Requirements 

Requirements  Management,  SP  1.2-1  -  Obtain  Commitment  to  Requirements 
Requirements  Development,  SP  1.1-1  -  Collect  Stakeholder  Needs 
Requirements  Development,  SP  1.1-2  —  Elicit  Needs 
Requirements  Development,  SP  1.2-1  -  Transform  Stakeholder  Needs, 
Expectations,  Constraints,  and  Interfaces  into  Customer  Requirements 
Requirements  Development,  SP  2.1-1-  Establish  Product  and  Product 
Component  Requirements 

Requirements  Development,  SP  3.3-1  -  Analyze  Requirements 
Requirements  Development,  SP  3.5-1  -  Validate  Requirements 
Requirements  Development,  SP  3.5-2  -  Validate  Requirements  with 
Comprehensive  Methods 

Technical  Solution,  SP  2.2-1  -  Develop  a  Technical  Data  Package 
Technical  Solution,  SP  2.2-3  -  Establish  a  Complete  Technical  Data  Package 
Product  Integration,  SP  1.1-1  -  Establish  a  Product  Integration  Strategy 

DoD  5000.2-R:  C2. 7.2-  Interoperability 

C2.8.5  -  Human  Systems  Integration  (HSI) 

C4.4  -  Affordability 

C4.5.4  -  Manpower 

C5.2.3.1  -  Requirements  Analysis 

C5.2.3.5.9  -  Human  Systems  Integration  (HSI) 

SE  OSDs:  SE1 30  -  Identify  Constraints  and  Analyze  Operational  Requirements 


3 2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

Much  of  the  early  work  in  developing  a  system  involves  the  definition  and  decomposition 
of  requirements.  Requirements  from  a  variety  of  sources  and  disciplines  must  be 
analyzed  to  remove  conflicts.  The  human  engineer  is  primarily  responsible  for  two  types 
of  requirements,  human  performance  requirements  and  human  engineering  design 
requirements.  Human  performance  requirements  include  times  and  accuracies  for  tasks 
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assigned  to  humans.  The  human  engineer  must  ensure  that  the  proposed  requirements  are 
in  fact  achievable  by  the  intended  operators  and  users.  The  human  engineer  may  in  some 
cases  define  the  human  performance  requirements  based  on  external  requirements, 
specifications  of  other  system  components,  or  the  capabilities  and  limitations  of  the 
prospective  operators  and  users.  The  human  engineering  design  requirements  concern 
specific  aspects  of  the  hardware  and  software  that  are  necessary  to  fit  the  operators  and 
assist  them  in  their  assigned  tasks.  These  requirements  define  what  must  be  designed  and 
constructed  to  permit  the  operators  and  users  to  interact  with  one  another  and  the  rest  of 
the  system.  Human  engineering  input  is  required  to  ensure  the  completeness  of  system 
requirements  involving  users  or  operators. 

Human  performance  requirements  are  frequently  derived  from  or  at  least  bounded  by 
other  performance  requirements  levied  on  the  system  such  as  the  time  available  to 
complete  an  action  or  to  make  a  decision.  The  accuracy,  response  time,  and  other 
attributes  of  the  operator  tasks  will  affect  the  ability  of  the  system  to  satisfy  related 
requirements  at  the  system  level.  Therefore,  the  human  performance  requirements  should 
be  in  a  format  similar  to  that  of  the  system-level  requirements.  Common  format  within  a 
given  project,  both  visually  and  electronically,  will  make  the  derivation  of  human 
performance  requirements  easier,  and  it  will  also  make  the  verification  or  approval  of 
those  requirements  by  the  systems  engineers  a  simpler  task.  Other  domains  will  also  be 
more  apt  to  incorporate  requirements  in  a  format  similar  to  their  own.  In  the  same  way, 
the  human  engineering  design  requirements  should  share  a  common  format.  In  the  case 
of  these  requirements,  a  common  format  is  even  more  important  as  they  must  be 
reviewed  or  followed  by  system  designers  in  other  disciplines.  Although  the  human 
engineer  is  the  one  who  may  set  specifications  for  the  design  of  other  system 
components,  the  complete  design  and  construction  of  those  components  will  be  the 
responsibility  of  others  within  the  project.  As  designs  become  more  detailed,  a 
continuous  interaction  between  the  human  engineer  and  other  disciplines  becomes  more 
valuable.  The  implementation  of  the  requirements  needs  to  be  verified,  and  additional 
design  decisions  need  to  be  made  as  the  design  progresses. 

IEEE  1220-1998:  6.1.11  -  Define  performance  requirements 

6.1.14  -  Define  design  characteristics 
EIA-632:  Requirement  4  -  Process  Implementation  Strategy 

Requirement  5  —  Technical  Effort  Definition 
Requirement  10  -  Progress  Against  Requirements 
Requirement  13  -  Information  Dissemination 
Requirement  14  -  Acquirer  Requirements 
Requirement  15  -  Other  Stakeholder  Requirements 
Requirement  16  -  System  Technical  Requirements 
Requirement  19-  Specified  Requirements 
Requirement  25  -  Requirement  Statements  Validation 
Requirement  26  -  Acquirer  Requirements  Validation 
Requirement  27  -  Other  Stakeholder  Requirements  Validation 
Requirement  28  -  System  Technical  Requirements  Validation 
Requirement  29  —  Logical  Solution  Representations  Validation 
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SE/SW  CMM:  Requirements  Management,  SP  1.1-1  Obtain  an  Understanding  of 

Requirements  _  .  . 

Requirements  Management,  SP  1.2-1  -  Obtain  Commitment  to  Requirements 

Requirements  Development,  SP  1.1-1-  Collect  Stakeholder  Needs 
Requirements  Development,  SP  1.1-2  -Elicit Needs 
Requirements  Development,  SP  1.2-1  -  Transform  Stakeholder  Needs, 
Expectations,  Constraints,  and  Interfaces  into  Customer  Requirements 
Requirements  Development,  SP  2.1-1  -  Establish  Product  and  Product 
Component  Requirements 

Requirements  Development,  SP  2.3-1-  Identify  Interface  Requirements 
Requirements  Development,  SP  3.3-1  -  Analyze  Requirements 
Requirements  Development,  SP  3.5-1  -  Validate  Requirements 
Requirements  Development,  SP  3.5-2  -  Validate  Requirements  with 
Comprehensive  Methods 

Technical  Solution  SP  2.2-1  -  Develop  a  Technical  Data  Package 
Technical  Solution,  SP  2.2-3  -  Establish  a  Complete  Technical  Data  Package 

DoD  5000.2-R:  Cl. 2  -  Thresholds  and  Objectives 

Cl. 4-  Acquisition  Program  Baseline  (APB) 

C2.2  -  Requirements 

C2.8.5  -  Human  Systems  Integration  (HSI) 

C2.8.6  -  Environment,  Safety,  and  Occupational  Health  (ESOH) 
Considerations 

C5.2.3.1  -  Requirements  Analysis 

C5.2.3.5.9- Human  Systems  Integration  (HSI) 

C5.2.3.5.10  -  Environment,  Safety,  and  Occupational  Health  (tb<J  ) 

SE  OSDs:  SE130  -  Identify  Constraints  and  Analyze  Operational  Requirements 

SE140  -  Identify  Functional  and  Performance  Requirements 


3.3  FUNCTION  ANALYSIS 

Function  analysis  involves  the  translation  or  allocation  of  the  system’s  requirements  to  a 
functional  architecture  that  defines  how  the  system  will  meet  those  requirements.  The 
functional  architecture  does  not  include  references  to  function  allocation  or 
implementation  Once  a  set  of  functions  that  satisfy  the  requirements  has  been  identified, 
thev  are  decomposed  into  greater  levels  of  detail,  and  interaction  between  the  functions  is 
defined.  Examples  of  inputs  and  products  produced  as  part  of  or  with  the  aid  of  human 
engineering  activities  in  this  stage  are  provided  m  Table  3-6. 

Function  analysis  is  more  easily  completed  without  consideration  of  human )^0^e™ent 
in  the  system,  but  many  of  the  products  of  function  analysis  are  critical  for  later  human 
engineering-related  activities.  Specific  functions  related  to  human  involvement  have  o 
be  identified,  and  information  and  decision  requirements  related  to  functions  need  to  be 
defined  so  that  they  may  be  used  as  criteria  in  later  function  allocation  decisions.  A 
userisdecision-rniingprocess,  for  example,  needs  to  be  well  defined  during  function 
analysis  whether  the  user  is  making  that  decision  alone  or  with  the  aid  of  decision- 
support  software. 
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Table  3-6.  Human  Engineering  Inputs  and  Products  in  Function  Analysis 


Inputs 

•  Mission  analyses 

•  Comparative  system  analyses 

•  Activity  analyses 

•  Requirements  analyses 

•  Subject  Matter  Expert  inputs 


Products 

•  Critical  functions 

•  Additional  functions  for  user  support 

•  Functional  architecture 

•  Function  flow  diagrams 

•  Decision-action  diagrams 

•  Information  flow  charts 

•  Support  requirements  for  users 

•  Required  design  characteristics  to  support 

users 


3.3.1  Functional  Decomposition 

A  high-level  set  of  desired  system  functions  is  typically  specified  very  early  in  the 
development  of  a  system  and  derived  from  a  high-level  requirements  document  like  an 
Operational  Requirements  Document.  These  top-level  functions  must  then  be  broken 
down  into  their  component  sub  functions  that  meet  the  system’s  requirements  within  the 
specified  constraints.  Once  the  functions  have  been  defined  and  decomposed  to  the 
lowest  level,  they  can  be  allocated  to  be  performed  by  humans,  hardware,  software,  or 
combinations.  Until  the  functions  can  be  decomposed  to  a  detailed  level,  most 
allocations  will  be  somewhere  between  “fully  manual”  and  “fully  automated.  A  single 
function  can  often  be  decomposed  in  a  variety  of  ways.  Choosing  the  best  decomposition 
before  function  allocation  decisions  are  made  can  reduce  later  design  changes. 


Decisions  on  function  allocation  are  typically  made  iteratively  as  functional 
decomposition  continues.  Allocating  the  functions  permits  their  parameters  to  be 
specified  in  greater  detail  and  serves  to  verify  the  decomposition.  Decomposition  of  the 
functions  must  continue  since  the  attributes  of  the  subfunctions  are  needed  to  support 
design  decisions.  Although  the  definition  and  decomposition  of  functions  is  independent 
of  allocation  and  may  be  seen  as  not  relevant  to  the  human  engineer,  the  results  of  the 
decomposition  and  analysis  will  be  used  in  later  design  work.  Much  of  the  information 
that  is  critical  to  the  human  engineer  may  not  be  of  interest  to  those  performing  the 
decomposition.  Timing  requirements,  available  information,  required  information,  and 
other  inputs  may  be  necessary  for  subsequent  human  engineering  design  decisions.  The 
optimal  way  to  ensure  that  the  necessary  information  is  defined  is  to  have  the  human 
engineer  work  in  conjunction  with  other  designers.  This  collaboration  will  allow  the 
definition  of  function  parameters  required  for  the  work  of  the  human  engineer.  The 
alternative  is  to  wait  until  the  human  engineer  needs  additional  information  and  either 
request  the  necessary  information  or  generate  it  at  that  point.  Any  new  functional 
information  that  the  human  engineer  independently  generates  will  need  to  be  reviewed 
and  verified  by  other  designers. 
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IEEE  1220-1998  6.3.1  -  Functional  context  analysis 

6.3.2-  Functional  decomposition 

E1A-632:  Requirement  17  -  Logical  Solution  Representations  .  .  , 

SE/SW  CMM:  Requirements  Development,  SP  3.2-1  -  Establish  a  Definition  of  equire 

Functionality 

DoD  5000.2-R:  C5.2.3.2  -  Functional  Analysis/Allocation 

SE  OSDs:  SE210-  Functional  Definition 


2.3.2  Review  of  Functional  Architecture 

The  functional  architecture  of  a  system  represents,  without  specifying  allocations,  what  a 
system  needs  to  do  to  meet  its  requirements.  The  architecture  includes  the  required 
functions,  the  flow  and  timing  between  functions,  and  their  respective  inputs  and  ^puts. 
As  with  functional  decomposition,  the  functional  architecture  is  highly  relevant  to  the 
human  engineer  despite  the  fact  that  it  does  not  explicitly  include  any  allocation 
decisions  The  functional  architecture  does,  however,  depend  upon  some  allocation 
decisions.  Some  functions  are  required  in  order  to  support  specific  implementation 
options.  For  example,  a  system  with  a  nuclear  power  source  will  have  a  refueling 
function  just  as  other  implementations  do,  but  the  timing  of  the  function  is  likely  to  be 
longer  inboth  duration  and  periodicity.  If  humans  are  to  be  included  as  partofa  system, 
functions  such  as  life  support,  food  supply,  communications,  supervision,  and  decision 
support  are  relevant  and  must  therefore  be  reflected  in  the  functional  architecture. 

It  is  the  human  engineer’s  responsibility  to  review  the  functional  architecture  ^ensure 
that  it  includes  all  aspects  relevant  to  the  inclusion  of  humans  in  the  system  and  their 
projected  roles.  In  the  case  of  top-level  system  requirements  the  human  engineer  can 
provide  feedback  as  to  whether  or  not  additional  high-level  functions  need  to  be  added  to 
account  for  the  role  of  humans  proposed  in  the  system  concept.  While  it  is  likely  that  few 
if  any  functions  are  added  at  this  level,  additional  functions  may  be  catalogued  or 
inclusion  during  functional  decomposition.  The  functional  flow  of  the  system  needs  to  be 
assessed  to  ensure  that  it  is  compatible  with  the  inclusion  of  humans  in  the  system. 
Enhanced  analysis  is  possible  as  more  allocation  decisions  are  made  and  as  greater  levels 
of  decomposition  are  reached.  The  functional  architecture  needs  to  be  compared  to  the 
human  engineering  requirements,  specifically  human  performance  requirements,  o 
determine  whether  or  not  those  requirements  can  be  satisfied  by  the  functional 
architecture. 


IEEE  1220-1998:  6.3.3  —  Establish  functional  architecture 

6.4  —  Functional  verification 

EIA-632:  Requirement  17  -  Logical  Solution  Representations  .  .  , 

SE/SW  CMM:  Requirements  Development,  SP  3.2-1  —  Establish  a  Definition  of  equire 

Functionality 

Verification,  SP  2.1-1  -  Prepare  for  Peer  Reviews 
Verification,  SP  2.2-1  -  Conduct  Peer  Reviews 
Verification,  SP  2.3-2  -Analyze  Peer  Review  Data 
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DoD  5000.2-R:  C2.8.5.4  -  Personnel  Survivability  and  Habitability 

C5.2.3.2  -  Functional  Analysis/Allocation 
C5.2.3.5.9.2  -  Habitability  and  Personnel  Survivability 
SE  OSDs:  SE210-  Functional  Definition 


3.4  FUNCTION  ALLOCATION 

The  goal  of  function  allocation  is  to  effectively  distribute  the  functions  of  the  system 
between  humans  and  technology.  The  functional  elements  are  identified  and  then  utilized 
in  the  creation  of  functional  element  allocation  options.  In  developing  these  allocation 
options  the  systems  engineer  considers  the  project  constraints,  requirements,  and  the 
capabilities  and  limitations  of  both  technology  and  the  users,  whether  as  individuals  or  as 
teams.  The  constraints  and  requirements  to  be  considered  are  usually  developed  early  in 
the  overall  process  when  the  systems  engineer  is  assessing  all  the  constraints  on  the 
system  and  its  operational  requirements.  The  systems  engineer  determines  the 
capabilities  and  limitations  of  the  potential  technologies,  as  well  as  the  possible  use  of 
commercial  off-the-shelf  products,  while  information  about  operator  capabilities  and 
limitations  will  come  from  the  human  engineer.  In  addition,  certain  functions  may  be 
required  to  be  allocated  specifically  to  operators  or  technology.  These  allocations  are 
made  first,  and  then  the  remaining  options  are  assessed  and  allocated.  This  mandatory 
function  allocation,  as  well  as  the  development  of  functional  element  allocation  options, 
is  an  important  step  in  the  systems  engineer’s  creation  of  implementation  concepts  or 
candidate  physical  architectures  for  the  system.  Samples  of  inputs  and  products  of  the 
collaboration  of  human  engineering  activities  with  other  system  development  activities 
are  shown  in  Table  3-7. 


Table  3-7.  Human  Engineering  Inputs  and  Products  in  Function  Allocation 


Inputs 

•  Function  allocation  evaluation  criteria 

•  Mission  analyses 

•  Comparative  system  analyses,  including 
knowledge,  skills,  and  abilities  (KSAs) 
of  operators/maintainers 

•  Activity  analyses 

•  Requirements  analyses 

•  Subject  Matter  Expert  inputs 

•  Function  analyses  (decision-action 
analyses,  information  flows,  function 
flows) 

•  Mandatory  allocations 

•  Technology  and  tradeoff  studies,  if 
available,  for  software  and  hardware 

•  Concept  of  operations 

•  Human  roles 


Products 

•  Allocations  of  system  functions  to  hardware, 
software,  humans,  or  combinations 

•  Support  requirements  for  users 

•  Required  design  characteristics  to  support 
users 

•  Predictions  of  knowledge,  skills,  and  abilities 
(KSAs)  for  user  tasks 

•  Predicted  staffing  and  training  needs 

•  Operational  sequence  diagrams 

•  Preliminary  procedure  requirements 

•  Predicted  workload 

•  Technology  &  tradeoff  studies  of  human- 
system  interface  technologies 

•  System  and  function  models 
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Since  details  of  human  capabilities  and  limitations  are  involved,  much  of  the  function 
allocation  responsibility  falls  into  the  realm  of  human  engineering.  One  way  for  the 
human  engineer  to  go  about  this  task  is  to  identify  the  capabilities  and  limitations  of  both 
the  potential  operators  and  available  technologies  and  then  weigh  the  various  options  to 
determine  possible  allocations.  The  human  engineer  first  determines  which  functions 
must  be  allocated  specifically  to  a  human  or  machine  and  then  conducts  the  tradeoffs  to 
develop  additional  potential  allocations.  Some  allocation  decisions  may  require  the 
definition  of  new  tasks  for  the  user,  such  as  the  addition  of  supervisory  and  monitoring 
tasks  for  an  automated  function.  The  mandatory  and  additional  allocation 
recommendations  are  preferably  codeveloped  by  the  human  engineer  and  systems 
engineer,  or  developed  independently  by  the  human  engineer.  The  systems  engineer 
must  then  approve  the  recommendations. 

The  process  of  allocating  functions  between  users,  software,  hardware,  and  combinations 
is  a  critical  step  in  improving  system  performance.  Unfortunately,  the  process  is  not  well 
supported  by  design  tools  and  is  commonly  performed  in  an  ad  hoc  manner  or  even 
omitted  as  an  explicit  step  in  the  development  process.  The  allocation  process  has  to  be 
based  on  effective  criteria  or  guidance  such  as  a  statement  of  intended  human  roles,  no 
solely  on  user  opinion  or  replication  of  implementations  from  previous  systems. 
Description  of  intended  roles  of  the  humans  within  the  system  -  whether  they  jj®  to  be 
primarily  supervisors,  monitors,  or  active  participants  -  is  critical  to  guiding  allocation 

decisions  and  later  software  development. 

Allocation  decisions  will  need  to  include  inputs  from  technology  experts,  but  an 
understanding  of  how  that  technology  impacts  the  users  is  also  required. 
performed  on  a  platform-by-platform  or  subsystem-by-subsystem  basis  need  to  address 
allocation  to  users  or  automation  as  part  of  that  process. 


3.4.1  Consideration  of  Human  Engineering  Technologies 

In  order  to  make  the  best  decisions  about  which  functions  should  be  allocated  to 
technology,  it  is  important  to  be  aware  of  the  types  of  technology  available  and  their 
inherent  capabilities  and  limitations.  The  systems  engineer  conducts  studies to  assess  the 
general  capabilities  and  limitations  of  the  technology  available  that  may  be  useful  for  the 
particular  system  under  design. 

The  human  engineer  may  conduct  additional  research  to  identify  technologies  capable  of 
supporting  or  replacing  humans  within  the  system  and  then  analyze  the  capabilities  of 
those  technologies.  Relevant  technologies  include  decision  support  systems,  human 
performance  models,  and  human-computer  interaction  techniques.  An  accurate 
assessment  of  the  potential  human  engineering  technology  allows  the  humanenzi  ez 
trade  off  these  factors  with  the  capabilities  and  limitations  of  the  operator.  The  human 
engineer’s  identification  of  the  human  engineering  technologies  and  assessment  of  t 
capabilities  and  limitations  should  be  done  with  the  help  of  other  disciplines  to  avoid 
duplication  of  work  and  ensure  common  assumptions. 
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The  human  engineer  can  eliminate  redundant  work  by  consulting  with  the  systems 
engineer  and  making  use  of  the  previous  systems  engineering  studies  of  technology 
capabilities  and  limitations.  Additionally,  the  human  engineer  can  aid  the  systems 
engineer  by  providing  necessary  data  about  the  user  population.  The  human  engineer 
will  consider  the  future  users  and  assess  their  capabilities  and  limitations  and  anticipated 
training  requirements.  These  capabilities  and  limitations  will  be  important  factors  in  the 
human  engineer’s  function  allocation  but  will  also  be  needed  by  the  systems  engineer  to 
assess  the  capabilities  and  limitations  of  the  system  as  a  whole. 

IEEE  1220-1998:  6.5.5  -  Assess  technology  requirements 

6.5.11  —  Develop  models  and  fabricate  prototypes 
EIA-632:  Requirement  5  -  Technical  Effort  Definition 

Requirement  16-  System  Technical  Requirements 
SE/SW  CMM:  Requirements  Development,  SP  2.3-1  -  Identify  Interface  Requirements 

Requirements  Development,  SP  3.4-3  —  Evaluate  Product  Cost,  Schedule,  and 
Risk 

Technical  Solution,  SP  1.1-2  -  Develop  Detailed  Alternative  Solutions  and 
Selection  Criteria 

Technical  Solution,  SP  1.3-1  -  Select  Product  Component  Solutions 
Technical  Solution,  SP  2.3-1  -  Establish  Interface  Descriptions 
Technical  Solution,  SP  2.3-4  -  Perform  Make,  Buy,  or  Reuse  Analyses 
DoD  5000.2-R:  C2.8.5.5  -  Human  Factors  Engineering 

C3.4  —  Developmental  Test  and  Evaluation  ( DT&E ) 

C5.2.3.5.9.1  -  Human  Factors  Engineering  (HFE) 

C7.5  -  Technology  Maturity 

SE  OSDs:  SE310  -  Synthesize  Multiple  Physical  Architectures 


3.4.2  Early  Identification  of  Mandatory  Allocations 

One  of  the  first  steps  in  allocation  is  the  identification  of  functions  that  must  be  allocated 
specifically  to  a  human  or  a  particular  technology.  For  example,  if  there  is  a  complicated 
numerical  calculation  that  must  be  completed  very  quickly,  this  should  probably  be 
allocated  to  software  components.  On  the  other  hand,  if  there  is  an  important  decision 
that  must  be  made,  such  as  whether  or  not  to  fire  on  a  potential  enemy,  it  may  be 
determined  that  this  function  should  not  be  left  to  a  machine  but  should  be  the  sole 
responsibility  of  an  operator.  The  systems  engineer  will  make  these  mandatory  allocation 
decisions,  based  in  part  on  recommendations  from  the  human  engineer. 

There  are  a  number  of  information  sources  that  might  be  important  for  the  human 
engineer  to  consider  while  developing  mandatory  allocation  decisions.  Information 
external  to  the  design  may  include  documents  such  as  the  Concept  of  Operations  or 
human  engineering  literature  applicable  to  the  design  domain.  Sources  of  information 
from  within  the  current  project  that  might  be  useful  include  the  system  use  scenarios  and 
the  variety  of  documents  outlining  requirements,  constraints,  and  capabilities/limitations. 
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The  systems  engineer  will  work  with  the  human  engineer  and  provide  him  with  a  variety 
of  information  sources  developed  by  the  systems  engineering  team,  including  the  list  ot 
functional  elements,  draft  functional  architectures,  and  cost  constraints.  The  systems 
engineer  and  human  engineer  should  also  consider  if  there  are  additional  technologies 
that  are  available  or  expected  to  be  available  that  should  be  investigated  for  an  optimal 
allocation.  If  so,  systems  engineering  trade  studies  might  be  conducted  to  assess  the 
options  and  the  results  of  these  studies  would  be  shared  with  the  human  engineer. 


The  development  and  approval  of  the  recommendations  for  the  mandatory  design 
allocation  follows  the  general  process  for  allocation  recommendations  (as  outlined 
below).  However,  it  is  important  to  note  that  the  human  engineer  should  consider  t  e 
mandatory  allocations  early  in  the  design  process  and  present  this  information  to  the 
systems  engineer.  If  the  mandatory  allocation  decisions  are  finalized  early,  this  can 
prevent  wasted  effort  on  designs  that  do  not  match  the  mandatory  requirements. 


IEEE  1220-1998:  6.5.1  -  Group  and  allocate  functions 

EIA-632:  Requirement  17  —  Logical  Solution  Representations 

Requirement  18  -  Physical  Solution  Representations 
SE/SW  CMM:  Requirements  Development,  SP  2.2-1  -  Allocate  Product  Component 

Requirements 

Technical  Solution,  SP  1.1-1-  Develop  Alternative  Solutions  and  Selection 

Criteria  , 

Technical  Solution,  SP  1.1-2  -  Develop  Detailed  Alternative  Solutions  and 

Selection  Criteria 

Technical  Solution,  SP  1.3-1  -  Select  Product  Component  Solutions 
DoD  5000.2-R:  C2.8.5.5  -  Human  Factors  Engineering 

C5.2.3.2  -  Functional  Analysis/Allocation 

C5. 2.3.5. 9.1  -  Human  Factors  Engineering  (HFE) 

SE  OSDs:  SE310  -  Synthesize  Multiple  Physical  Architectures 


3  4  3  Development  and  Approval  of  Function  Allocation  Recommendations 

Both  the  mandatory  function  allocations  and  the  additional  allocations  that  follow  must 
be  developed  by  taking  into  account  a  number  of  factors  and  considering  a  variety  of 
information  from  different  sources.  This  can  be  a  complicated  step  in  the  design  where 
conflicting  costs  and  benefits  require  careful  tradeoffs.  If  the  allocation  decision  is 
ambiguous,  systems  engineering  trade  studies  or  human  engineering  studies,  such  as  user 
review  or  performance  and  workload  estimation,  may  need  to  be  performed  to  generate 
the  information  required  to  make  the  decision.  The  systems  engineer,  human  engineer 
and  other  designers  will  ideally  generate  the  allocation  recommendations  jointly,  but  they 
may  instead  be  developed  independently  by  the  human  engineer  and  submitted  to  the 
systems  engineer  for  approval.  If  the  human  engineer  prepares  the  options,  then  the 
expectations  of  the  systems  engineer  (i.e.,  number  and  variety  of  options  desired)  should 

be  taken  into  account. 
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Once  the  recommendations  are  developed,  they  must  be  approved  by  the  systems 
engineer.  If  the  systems  engineer  was  also  involved  in  development,  then  the  approval 
should  be  a  simple  step.  However,  if  the  human  engineer  developed  the 
recommendations  independently,  the  systems  engineer  may  have  feedback  or  suggestions 
for  changes.  In  addition,  the  systems  engineer  should  be  aware  of  other  influential 
decisions  that  might  have  been  made  or  are  being  considered.  Thus,  the  systems  engineer 
should  be  able  to  take  into  account  the  objectives  of  the  human  engineer’s  suggested 
allocation  and  the  objectives  of  the  activities  of  other  disciplines.  This  may  be  an 
iterative  process  of  refinement  until  the  systems  engineer  and  human  engineer  can  agree 
on  a  set  of  allocations. 

IEEE  1220-1998:  6.5.1  -  Group  and  allocate  functions 

EIA-632:  Requirement  17-  Logical  Solution  Representations 

Requirement  18  -  Physical  Solution  Representations 
SE/SW  CMM:  Requirements  Development,  SP  2.2-1  -  Allocate  Product  Component 

Requirements 

Technical  Solution,  SP  1.1-1  -  Develop  Alternative  Solutions  and  Selection 
Criteria 

Technical  Solution,  SP  1.1-2  -  Develop  Detailed  Alternative  Solutions  and 
Selection  Criteria 

Technical  Solution,  SP  1.3-1  -  Select  Product  Component  Solutions 
DoD  5000.2-R:  C2.8.5.5  -  Human  Factors  Engineering 

C5.2.3.2  -  Functional  Analysis/Allocation 

C5. 2. 3. 5. 9.1  -  Human  Factors  Engineering  (HFE) 

SE  OSDs:  SE310  -  Synthesize  Multiple  Physical  Architectures 


3.5  TASK  DESIGN  AND  ANALYSIS 

Once  the  functions  of  a  system  have  been  assigned  to  particular  system  components,  the 
functions  can  typically  be  defined  to  greater  resolution  of  detail.  What  was  a  generalized 
function  must  be  expanded  to  describe  exactly  how  the  specified  system  components  will 
accomplish  the  functions.  The  allocation  of  a  function  to  a  human  creates  or  defines  what 
is  typically  referred  to  as  a  task.  Given  the  constraints  of  the  system’s  requirements  and 
functional  architecture,  the  human  engineer  needs  to  define  precisely  how  the  humans 
within  the  system  will  carry  out  their  assigned  tasks.  The  human  tasks  include  both  tasks 
that  humans  do  alone  and  tasks  that  involve  their  interaction  with  other  parts  of  the 
system.  The  order  and  interactions  of  the  tasks  can  be  defined  and  modeled  to  verify  that 
they  meet  the  system  requirements.  Examples  of  both  inputs  to  and  products  of  Task 
Design  and  Analysis  are  listed  in  Table  3-8. 

Without  an  explicit  effort  in  task  design,  user  tasks  in  an  implemented  system  will  not 
conform  to  user  needs  and  activities.  Systems  commonly  end  up  with  user  interfaces  that 
arrange  information  on  the  basis  of  information  sources  instead  of  task  order,  frequency 
of  use,  or  other  attributes  of  the  task.  Even  minor  interface  manipulation  tasks  -  such  as 
an  extra  mouse  click  to  access  or  close  a  data  window  —  can  have  a  significant  impact  on 
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Table  3- 

Inputs 


■8.  Human  Engineering  Inputs  and  Products  in  Task  Design  and  Analysis 


Mission  analyses 

Comparative  system  analyses,  including 
knowledge,  skills,  and  abilities  (KSAs) 
of  users 

Activity  analyses 
Requirements  analyses 
Subject  Matter  Expert  inputs 
Function  analyses  (decision-action 
analyses,  information  flows,  function 
flows) 

Allocations  of  system  functions  to 
hardware,  software,  humans  or 
combinations 

Technology  and  tradeoff  studies,  if 
available,  for  software,  hardware,  and 
human  engineering  technologies 

Functional  element  allocation  options 
Physical  architecture 
System  and  function  models 


Products 

•  Task  list 


Task  interactions  and  sequences 

Task  models 

Timeline  analyses 

Support  requirements  for  users 

Required  design  characteristics  to  support 

users 

Simulations  and  prototypes 

Predictions  of  knowledge,  skills,  and  abilities 

(KSAs)  for  user  tasks 

Predicted  staffing  and  training  needs 

Preliminary  procedure  requirements 

Preliminary  predictions  of  cognitive  and 

physical  workload 

Preliminary  predictions  of  human  and  system 
performance 


human  and  system  performance  if  they  occur  frequently.  Both  the  frequency  and 
duration  of  human  tasks  need  to  be  estimated  to  adequately  evaluate  designs. 


3.5.1  Development  of  the  Task  List 

Before  the  analysis  of  the  tasks  of  the  humans,  it  is  necessary  to  compile  a  complete  list 
of  the  tasks  to  be  considered.  This  process  may  also  include  the  decomposition  of  tasks, 
if  such  decomposition  would  be  useful.  Most  likely,  the  human  engineer  will  be 
responsible  for  creating  the  task  list;  however,  he  or  she  may  want  to  work  with  t 
svstems  engineer  and  engineers  in  other  domains  to  achieve  a  better  understanding  of  the 
tasks  Systems  engineering  documents,  such  as  the  functional  element  allocation  options 
and  the  physical  architecture,  may  be  of  great  use  to  the  human  engineer  by  Priding  a 
context  for  the  tasks.  The  systems  engineer  might  also  provide  additional,  amplify  g 
information,  such  as  decisions  by  other  disciplines  that  influence  the  tasks  of  the  humans. 

The  human  engineer  will  assess  the  information  from  the  systems  engineer  and  other 
design  engineers  and  devise  a  complete  list  of  human  tasks.  Both  physical  and  cogmtive 
tasks  willhave  to  be  considered,  and  a  wide  variety  of  methodologies  can  be  employed  to 
do  so  Additional  inputs  to  the  development  of  the  task  list  include  the  approved  function 
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allocations  and  interface-specific  tasks,  if  applicable.  Interface-specific  tasks  are  those 
that  are  created  as  a  function  of  the  interface  that  is  chosen,  and  are  based  on  the  interface 
concepts  and  designs.  Interface-specific  tasks  are  normally  defined  following  task 
design;  however,  due  to  the  iterative  nature  of  the  design  process,  the  human  engineer 
may  redevelop  the  task  list  in  light  of  later  decisions. 

IEEE  1220-1998:  6.5.2  -  Identify  design  solution  alternatives 

EIA-632:  Requirement  17-  Logical  Solution  Representations 

Requirement  18  -  Physical  Solution  Representations 
SE/SW  CMM:  Technical  Solution,  SP  1.1-2-  Develop  Detailed  Alternative  Solutions  and 

Selection  Criteria 

Technical  Solution,  SP  1.2-2  -  Evolve  Operational  Concepts  and  Scenarios 
Technical  Solution,  SP  2.2-3  -  Establish  a  Complete  Technical  Data  Package 
DoD  5 000.2 -R:  C5.2.3.5.9.1  -  Human  Factors  Engineering  (HFE) 

SE  OSDs:  SE320  -  Evaluate  and  Select  Preferred  Architecture 


3.5.2  Identification  of  Task  Characteristics,  Interactions,  and  Sequences 

Once  the  task  list  has  been  generated,  the  particular  characteristics  of  each  task  must  be 
outlined.  This  further  definition  facilitates  a  better  understanding  of  the  individual  tasks 
and  can  be  used  in  other  steps  of  the  task  design  and  analysis  process,  such  as  task 
allocation  and  definition  of  required  skills  and  abilities.  In  order  to  attain  a  full 
understanding  of  the  tasks,  the  interactions  between  the  tasks  or  the  possible  sequences  in 
which  they  will  be  accomplished  should  also  be  identified.  The  identification  of 
interactions  and  sequences  among  tasks  is  important  both  to  better  characterize  the  tasks 
themselves  and  also  to  create  accurate  task  models. 

The  task  design  and  analysis  portion  of  the  human  engineering  process  might  be  highly 
iterative,  and  the  results  of  both  these  identifications  can  act  as  inputs  for  each  other. 
Additional  information  sources  might  include  the  human  engineer’s  task  list  and  the 
externally  set  operational  requirements.  Systems  engineering  contributions  include  the 
functional  element  allocation  options  and  general  systems  engineering  guidance  on  the 
current  system  design.  This  systems  engineering  advice  is  imperative  in  order  to 
accurately  identify  interactions  with  nonhuman  elements  of  the  system.  These  task 
interactions  include  interactions  between  humans  and  automated  functions  and/or  other 
system  components.  The  need  for  users  to  monitor  or  supervise  automated  systems  must 
be  addressed. 

There  is  also  an  interaction  between  the  human  engineer  and  systems  engineer  because 
the  human  engineer’s  task  definition  is  dependent  on  the  system  design,  since  this  design 
will  impact  the  possible  ways  to  accomplish  the  tasks.  The  human  engineer  can  create 
the  most  useful  set  of  task  characteristics  only  by  checking  with  the  systems  engineer  to 
verify  that  the  human  engineer  has  a  correct  understanding  of  the  system  design.  The 
most  accurate  representation  of  the  system  design  is  probably  embodied  in  the  systems 
engineer’s  current  candidate  physical  architectures.  The  systems  engineer’s  functional 
decomposition  will  also  be  useful  to  consider.  If  the  decomposition  is  not  to  the  level  of 
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detail  required  by  the  human  engineer,  a  further  functional  analysis  may  be  necessary. 
Other  useful  sources  for  determining  if  all  tasks  have  been  identified  are task  llstings 
from  comparable  systems.  These  may  not  be  applicable  to  the  system  under  design,  bu 

they  can  help  provide  cues  for  finding  missing  tasks. 

IEEE  1220-1998:  6.5.2  —  Identify  design  solution  alternatives 

EIA-632:  Requirement  17  -  Logical  Solution  Representations 

Requirement  18  -  Physical  Solution  Representations 

Technical  Solution,  SP  1.2-2 -Evolve  Operational  Concepts  and  Scenarios 
Technical  Solution,  SP  2.2-3  -  Establish  a  Complete  Technical  Data  Package 
DoD  5000.2-R:  C5.2.3.5.9.1  -  Human  Factors  Engineering  (HFE) 

SE  OSDs:  SE320  —  Evaluate  and  Select  Preferred  Architecture 


3  5  3  Selection  of  Modeling  Tools  and  Techniques 

Modeling  techniques  are  typically  used  to  evaluate  or  compare  candidate  designs. 

Models  can  be  constructed  at  the  functional  level  or  in  the  context  of  the  system  s 
implementation.  Creating  models  of  external  systems  can  help  to  define  functional  a 
performance  requirements  for  the  system  under  development.  The  utility  of  mode 1  8 
techniques  and  executable  models  (i.e.,  models  that  can  run,  or  execute  in  a  simula  ed 
environment)  in  particular  can  be  significantly  increased  if  models  used  by  different 
designers  are  interoperable.  Systems  engineers  can  then  create  higher-level  models  o 
system  by  combining  models  developed  for  different  subsystems  or  within  different 

disciplines. 

An  important  step  for  the  human  engineer  in  task  design  and  analysis  is  to  select 
appropriate  task-level  tools  and  techniques  that  will  result  in  a  useful  and  appropriate 
model  The  tools  and  techniques  should  be  chosen  early  enough  to  ensure  that  they  can 
support  the  inclusion  of  relevant  information  from  the  task  analysis.  These  mode  mg 
tools  and  techniques  will  determine  how  the  task  list,  task  characteristics,  and  tas 
interactions  and^equences  will  be  used  to  create  task  models.  Comments  from  subject 
matter  experts  might  also  be  useful  in  tailoring  and  validating  task  models.  In  order  t 
have  task  models  that  are  compatible  with  system-level  models  and  models  from  other 
design  disciplines,  the  human  engineer  and  systems  engineer  must  agree  on  the  mode  g 
tools  to  be  utilized.  The  human  engineer  should  also  request  the  systems  engineer  s  inpu 
on  the  models,  since  they  will  include  nonhuman  elements.  Since  model  development 
can  take  considerable  time  and  resources,  communication  between  the  systems  engineer 
and  human  engineer  is  important  to  ensure  that  the  models  selected  can  be  used  across 
design  disciplines.  Given  the  importance  of  resource  allocation  to  support  systern  and 
subsystem  modeling,  overall  project  plans  should  include  human  engineering  modeling 

as  a  program  milestone. 


IEEE  1220-1998: 


EIA-632: 


998:  6.5.2  -  Identify  design  solution  alternatives 

6.5.11  -  Develop  models  and  fabricate  prototypes 
Requirement  5  -  Technical  Effort  Definition 
Requirement  13  —  Information  Dissemination 
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Requirement  23  —  Tradeoff  Analysis 

SE/SW  CMM:  Technical  Solution,  SP  2.1-1  -  Use  Effective  Design  Methods 

Verification,  SP  1.1-1-  Establish  a  Verification  Strategy 
Validation,  SP  1.1-1  -  Establish  a  Validation  Strategy 
DoD  5 000.2 -R:  C5.2.3.5.2.3  -  Planning  the  M&S  Approach 

C5.2.3.5.2.4  -  M&S  Standards 

SE  OSDs:  SE320  -  Evaluate  and  Select  Preferred  Architecture 

SE330  -  Integrate  System  Physical  Configuration 


3.5.4  Task  and  Function  Audit 

In  synthesizing  the  physical  architecture,  allocations  between  humans  and  machines  will 
be  reflected  in  the  design  of  interfaces.  The  designers  will  have  to  verify  that  all 
functions  in  the  functional  architecture  can  be  traced  to  human  tasks  or  automated 
activities.  A  review  of  the  task  list  -  including  interface-  and  team-specific  tasks  - 
should  therefore  find  all  of  the  tasks  drawn  from  the  function  allocation  in  the  interface 
and  team  concepts  and  designs.  This  review  may  be  thought  of  as  an  audit  of  the 
interfaces  with  a  mandatory  consideration  of  all  of  the  tasks  from  the  analyses  and 
simulations. 

A  confirmation  of  automation  assumptions  by  the  systems  engineer  and  other  designers  is 
necessary  to  ensure  that  the  job  and  task  design  performed  by  the  human  engineer  does 
not  omit  necessary  functions.  The  human  engineer  may  need  to  give  feedback  to  the 
systems  engineer  about  tasks  that  could  be  automated  or  tasks  that  need  further  design 
support.  For  example,  further  function  analysis  may  be  required,  an  operator  may  need 
additional  information  to  support  decision-making,  or  additional  automation  or  system 
functionality  may  improve  system  performance. 

IEEE  1220-1998:  6.5.7  -  Define  physical  interfaces 

6.5.15  -  Final  design 

EIA-632:  Requirement  17-  Logical  Solution  Representations 

Requirement  18  -  Physical  Solution  Representations 
SE/SW  CMM:  Technical  Solution,  SP  2.1-1  -  Use  Effective  Design  Methods 

Verification,  SP  1.2-2  -  Establish  the  Verification  Environment 
Verification,  SP  2.1-1  -  Prepare  for  Peer  Reviews 
Verification,  SP  2.2-1  —  Conduct  Peer  Reviews 
Verification,  SP  2.3-2  -Analyze  Peer  Review  Data 
Verification,  SP  3.1-1  -  Perform  Verification 
DoD  5000.2-R:  C5.2  -  Systems  Engineering 

SE  OSDs:  SE320  -  Evaluate  and  Select  Preferred  Architecture 


3.6  HUMAN  INTERFACE  AND  TEAM  DEVELOPMENT 

Designs  and  concepts  for  the  interfaces  between  humans  and  software,  hardware,  and 
other  humans  need  to  be  identified  and  developed.  These  interfaces  can  be  considered  at 
three  different  levels: 
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1.  Individual  interfaces  that  represent  a  particular  interaction  based  on  the  task 
analysis  as  well  as  performance  and  design  requirements, 

2.  Combinations  of  interfaces  for  a  design  at  the  individual  operator  level  based  on 

the  combination  of  tasks  into  roles,  and 

3.  Interface  designs  and  concepts  for  multiple  operators  based  on  the  combination 
of  individuals  into  crews  or  teams. 

The  creation  of  the  separate  levels  of  interfaces  may  be  performed  in  any  order  depending 
on  the  availability  of  resources  and  the  priority  of  individual  user  versus  crew/team 
development.  Examples  of  some  of  the  inputs  and  products  related  to  these  human 
engineering  activities  are  shown  in  Table  3-9. 

Table  3-9.  Human  Engineering  Inputs  and  Products  in  Human  Interface  and  Team  Development - 


Inputs 


Products 


Operational  sequence  diagrams 
Information  and  decision  requirements 
Subject  Matter  Expert  inputs 


User  interface  concepts  and  designs 
Crew  and  team  concepts  and  designs 
User  interface  manipulation  tasks 
Team  coordination  tasks 
Link  analyses 

Simulations  and  prototypes 

Final  system-specific  HCI  style  guide 


User  interfaces,  unfortunately,  are  often  designed  at  the  component  or  subsystem  level 
instead  of  the  user  level.  The  entire  combination  of  subsystems  with  which  a  given i  user 
interacts  needs  to  be  designed  as  a  whole.  Similarly  roles  of 

based  on  more  than  assigning  each  user  to  a  particular  piece  of  equipment  The  roles  ot 
individual  users  within  a  team  need  to  be  explicitly  designed  instead  of  only  being  a 
function  of  how  capabilities  have  been  divided  between  pieces  of  equipment.  Fina  y, 
user  interfaces  and  team  designs  cannot  be  sufficiently  evaluated  without  user 
involvement  and  human  performance  testing,  and  evaluation  should  occur  while  time  and 

resources  remain  to  make  design  changes. 


3.6.1  Points  of  Human  Interface 

Points  of  human  interface  may  be  thought  of  as  the  content  and  the  location  (origin  and 
destination)  of  information  that  may  be  conveyed  between  system  components 
(specifically,  between  humans  or  between  a  human  and  a  machine).  Also  included  are 
the  data  to  be  transmitted,  the  nodes  or  elements  between  which  the  data  is  to  be 
transmitted,  when  the  data  is  transmitted  and  other  interface-specific  constraints,  such  as 
special  conditions  based  on  times  and  events.  These  points  will  be  used  in  the 
development  of  the  interface  concepts  and  designs  and  will  lead  to  interfaces  at  the 
individual  level  followed  by  the  crew/team  level. 
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The  human  engineer  must  identify  all  of  the  data  to  be  transmitted  and  the  location,  or 

nodes,  to  and  from  which  it  will  be  transmitted.  This  is  based  on  the  functional 
decomposition  and  allocation,  as  well  as  the  task  analysis  (which  includes  characteristics 
of  tasks  and  the  interactions  and  sequences),  and  any  available  internal  and  external 
interface  information  developed  to  that  point  by  the  systems  engineer.  These  system- 
level  interfaces  must  be  decomposed  for  application  to  the  level  of  automation. 

The  systems  engineer  helps  verify  allocation  assumptions  made  by  the  human  engineer 
and  document  the  flow  of  information  between  humans  and  automation  as  well  as 
identify  additional  points  in  the  allocated  functional  architecture  at  which  information  or 
material  is  passed  between  humans  and  other  system  components.  The  role  of  the  human 
engineer  is  to  keep  the  points  of  interface  in  line  with  the  initial  system-level  interfaces 
defined  earlier  in  the  systems  engineering  process  and  in  line  with  the  mission  goals  and 
constraints.  Some  interactions  may  be  identified  to  address  special  needs  or  preferences 
of  the  users,  such  as  creation  and  retrieval  of  user  profiles  or  display  configurations. 

IEEE  1220-1998:  6.1.7-  Define  interfaces 

6.3. 1.2  -  Define  functional  interfaces 
6.5.7  -  Define  physical  interfaces 
E1A-632:  Requirement  18  -  Physical  Solution  Representations 

SE/SW  CMM:  Requirements  Development,  SP  2.3-1  -  Identify’  Interface  Requirements 

Technical  Solution,  SP  2.3-1  -Establish  Interface  Descriptions 
Technical  Solution,  SP  2.3-3  -  Design  Comprehensive  Interface 
DoD  5000.2-R:  C2.8.5.5  -  Human  Factors  Engineering 

C5.2  -  Systems  Engineering 
C5.2. 3.5.5  -  Open  Systems  Design 
C5.2.3.5.9.1  -  Human  Factors  Engineering  (HFE) 

SE  OSDs:  SE210  -  Functional  Definition 

SE320  -  Evaluate  and  Select  Preferred  Architecture 


3.6.2  Selection  of  Human  Interface  and  Team  Guidelines 

For  the  development  of  interfaces  and  teams,  human  engineers  need  to  be  aware  of  any 
existing  guidelines  applicable  to  the  information  or  material  passed  between  humans  or 
between  humans  and  equipment.  The  guidelines  will  also  assist  in  keeping  the  design  in 
accordance  with  constraints,  heuristics  and  prior  research  of  the  particular  engineering  or 
design  community.  Guideline  topics  may  include,  but  are  not  limited  to,  short  term  and 
working  memory  limitations,  display  and  control  modalities,  physical  or  strength 
limitations,  and  group  dynamics.  These  guidelines  may  also  include  those  defined  in, 
derived  from,  or  implied  by  human  and  job/task  requirements  and  organizational  design. 

Collaboration  between  the  systems  engineer  and  human  engineer  on  the  selection  and 
implementation  of  standards  and  guidelines  will  help  identify  how  system-level 
guidelines  may  be  applicable  to  human  engineering  designs.  Full  application  of  system- 
level  guidelines  will  often  require  the  implementation  of  specific,  lower  level,  detailed 
guidelines.  For  example,  if  a  particular  computer  system  architecture  is  selected,  then 
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any  associated  user  interface  design  guidelines  should  be  implemented.  Collabomtion 
will  also  help  identify  how  guidelines  from  one  design  discipline  will  impact  other 
^dpUnefC  human  engineer  will  identify  additional  useful  guidelines,  eaeh  of  whtch 

may  impact  one  or  more  other  design  disciplines. 


IEEE  1220-1998:  6.1.3  —  Define  external  constraints 

6J.2.4- Define  data  and  control  flows 
EIA-632 ■  Requirement  18 -Physical Solution  Representations 

SE/SWCMM:  Requirements  Development,  SP  2.1-1  -  Establish  Product  and  Product 

Component  Requirements 

Technical  Solution,  SP  2.1-1  -  Use  Effective  Design  Methods 
Technical  Solution,  SP  3.1-1  -  Implement  the  Design 
Verification,  SP  1.1-1  -  Establish  a  Verification  Strategy 
Validation,  SP  1.1-1  -  Establish  a  Validation  Strategy 
DoD  5000.2-R:  C2.8.5.5  -  Human  Factors  Engineering 

C5.2.3.5.5  -  Open  Systems  Design 
C5.2.3.5.9.1  -Human  Factors  Engineering  (HFE) 

SE  OSDs:  SE130  -  Identify  Constraints  and  Analyze  Operational  Requirements 


DoD  5000.2-R: 


3.6.3  ripyplonment  of  Interface  and  Team  Concepts  or  Designs 

Once  an  initial  physical  architecture  has  been  synthesized  and  approved  by  the  systems 
engineer  the  interfaces  between  system  components  -  such  as  humans,  hardware,  and 
software  -  can  be  developed.  The  interaction  of  humans  with  other  system  components 
will  be  based  on  the  functional  architecture,  allocation  decisions,  and  human  engmeenng 
inputs  Some  elements  of  interfaces  both  internal  and  external  to  the  system  will 
already  been  defined  as  interfaces  between  functions  within  the  functional  architecture. 

The  human  engineer  will  be  responsible  for  designing  and  optimizing  how  individual 
humansinteract  with  nonhuman  system  components  and  how  humans  act  together  as 
teams.  Interface  concepts  and  designs  are  developed  based  on  requirements  or 
interaction  between  humans  and  other  system  components  specified  earlier. 

Reauirements  such  as  the  transfer  of  information,  timing,  need  for  minimizing 
*  «cln,  and  physical  location  must  all  be  satisfied  by  the  interface  designs^  Due 
to  the  potentially  significant  and  varied  amount  of  information  to  be  transferred,  he 
process  of  developing  team  and  individual  interface  concepts  and  designs  is  highly 
creative.  The  concepts  are  less  detailed  and  concrete  than  the  designs  but  are  highly 
iterative  with  their  development,  as  they  feed  off  of  each  other  The  developmen  o 
interfaces  includes  their  physical  appearances  and  procedures  for  use.  Interface 
guidelines  and  standards  will  influence  the  design  of the  mterfaces^I^ 
considered  collectively,  in  combinations,  in  order  to  mmimize  conflic  s  between  different 
interfaces  encountered  by  a  single  operator  or  user.  Team  designs  will  be  based  on  th 
allocation  of  tasks  and  other  responsibilities  to  different  operators  or  team  members,  and 
will  be  influenced  by  such  factors  as  individual  workload  and  performance  levels,  team 
design  principles,  and  overall  performance  requirements. 
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Team  and  individual  interface  design  will  be  highly  constrained  due  to  other  design 
decisions,  such  as  specific  pieces  or  types  of  hardware  and  software  that  are  to  be  used. 
The  human  engineer  attempts  to  develop  team  and  interface  designs  that  provide  for 
optimal  system  performance  within  those  constraints.  The  human  engineer  requires  input 
from  the  systems  engineer  on  system-level  constraints  (particularly  those  imposed  by 
other  design  decisions),  project  and  enterprise  constraints,  off-the-shelf  availability, 
make-or-buy  alternatives,  state-of-the-art  capabilities,  design  solution  alternatives,  etc.  In 
some  cases,  constraints  and  design  decisions  that  have  been  made  previously  may  need  to 
be  reevaluated  based  on  analysis  of  human  performance  within  those  constraints  as  well 
as  interaction  with  other  design  disciplines  to  ensure  the  feasibility  of  the  proposed 
designs. 

IEEE  1220-1998:  6.1.2  -  Define  project  and  enterprise  constraints 

6.1.3  -  Define  external  constraints 

6.1.7  -  Define  interfaces 

6.3.2.4  -  Define  data  and  control  flows 

6.5.7  -  Define  physical  interfaces 

EIA-632:  Requirement  18  -  Physical  Solution  Representations 

SE/SW  CMM:  Technical  Solution,  SP  1.1-1  -  Develop  Alternative  Solutions  and  Selection 

Criteria 

Technical  Solution,  SP  1.1-2  -  Develop  Detailed  Alternative  Solutions  and 
Selection  Criteria 

Technical  Solution,  SP  2.2-1  -  Develop  a  Technical  Data  Package 
Technical  Solution,  SP  2.2-3  -  Establish  a  Complete  Technical  Data  Package 
Technical  Solution,  SP  2.3-1  -  Establish  Interface  Descriptions 
Technical  Solution,  SP  2.3-3  -  Design  Comprehensive  Interface 
Product  Integration,  SP  2.1-1  -  Review  Interface  Descriptions  for 
Completeness 

DoD  5000.2-R:  C2.8.5.5  -  Human  Factors  Engineering 

C5.2.3.3  -  Design  Synthesis  and  Verification 
C5.2.3.5.9.1  -  Human  Factors  Engineering  (HFE) 

SE  OSDs:  SE130  -  Identify  Constraints  and  Analyze  Operational  Requirements 


3.7  PERFORMANCE,  WORKLOAD,  AND  TRAINING  LEVEL  ESTIMATION 

The  systems  engineer  must  evaluate  the  design  or  design  options  proposed  by  system 
designers  within  the  different  disciplines.  Evaluation  of  a  single  option  is  necessary  to 
determine  whether  or  not  the  system  requirements  are  satisfied,  and  multiple  options  may 
be  evaluated  in  order  to  make  a  selection.  The  systems  engineer  may  determine  which 
options  meet  requirements  and  then  select  the  best  alternative,  or  the  best  option  may  be 
selected  and  then  compared  to  the  requirements.  Overall  system  performance  is  an 
important  parameter,  but  it  typically  consists  of  multiple  variables  that  may  be  measured 
within  different  design  disciplines.  The  design  evaluations  provided  by  different 
disciplines  will  all  need  to  be  available  to  the  systems  engineer  to  enable  the  tradeoff  of 
different  design  options.  Examples  of  the  inputs  to  and  products  of  these  human 
engineering  activities  are  listed  in  Table  3-10. 
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Table  3-10.  Human  Engineering  Inputs  and  Products  in  Performance,  Workload,  and  Training  Level 
Estimation  — 


Inputs 


Operational  sequence  diagrams 
Simulations  and  prototypes 
Predicted  user  knowledge,  skills,  and 
abilities  (KSAs) 

User  interface  concepts  and  designs 
Crew  or  team  concepts  and  designs 
Task  models 


Products 


Required  user  knowledge,  skills,  and  abilities 
(KSAs) 

Training  requirements 
User/personnel  selection  requirements 
Predicted  cognitive  and  physical  workload 
Predicted  human  and  system  performance 
Human  performance  and  workload  models 


To  help  in  the  evaluation  of  concepts  and  designs,  the  human  engineer  will  estimate  the 
physical  and  cognitive  workload  levels  of  individuals  and  teams  within  the  system. 
Workload  stressors  and  their  effects  on  human  performance  and  operator  coping 
strategies,  as  well  as  the  effects  of  task  neglect  or  delay,  need  to  be  defined  in  a  way  that 
allows  their  impact  on  system  performance  to  be  assessed.  Workload  and  the  resultant 
manning  and  training  requirements  are  to  be  optimized  to  meet  required  performance 

levels. 

User  performance  and  workload  can  be  difficult  to  estimate,  but  estimating  them  in 
isolation  is  not  sufficient.  The  impact  of  workload  on  performance  should  be  evaluated, 
and  human  performance  predictions  should  be  linked  to  system  performance.  Identifying 
how  human  performance  impacts  system  performance  enables  human  performance  data 
and  user  interface  features  to  be  part  of  system-level  tradeoff  analyses  With  respect  to 
training,  training  requirements  need  to  be  assessed  early  in  order  for  them  to  become  a 
factor  in  design  decisions. 

3.7.I  individual  anH  Team  Workload  and  Performance  Estimation 

Workload  levels  can  significantly  influence  the  performance  of  many  system  components 
or  subsystems,  including  humans.  Once  workload  levels  are  predicted,  performance 
measures  can  be  adjusted  to  determine  the  impact  of  workload.  Given  the  tasks  allocated 
to  humans,  the  human  engineer  needs  to  estimate  the  cognitive  and  physical  workload 
demands  of  the  tasks  on  the  operators  and  users.  Executable  models  or  simulations  are 
typically  used,  but  subjective  feedback  from  test  users  or  subject  matter  experts  may  also 
be  employed.  Workload  levels  must  be  estimated  for  different  scenarios  or  situations, 
and  changes  in  workload  level  can  be  as  important  as  the  absolute  levels  of  workload. 

The  scenarios  must  provide  the  conditions  to  elicit  realistic  workload.  For  example,  it 
sustained  operations  over  long  periods  are  required,  then  the  scenario  should  allow  for  it, 
or  if  there  is  a  reasonable  chance  that  many  conditions  could  occur  at  the  same  time,  then 
those  conditions  should  be  included.  Workload  on  the  team  as  a  whole  frequently 
quantified  as  the  time  required  to  complete  all  assigned  tasks,  also  needs  to  be  estimate  . 
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In  order  to  be  accurate,  workload  models  need  to  include  any  operator  or  user  tasks  that 
are  required  to  manipulate  or  utilize  the  human-machine  interface. 

To  effectively  estimate  workload  and  performance,  the  human  engineer  needs  up-to-date 
design  data  from  the  systems  engineer  and  other  designers.  In  order  to  create  accurate 
models  of  how  the  humans  interact  with  the  rest  of  the  system,  the  human  engineer  will 
need  access  to  models  of  other  system  components.  Without  an  accurate  simulation  of 
hardware  and  software  functions  and  performance,  the  model  of  the  human  interactions 
will  not  be  accurate.  Information  on  other  system  components  may  be  included  as  part  of 
an  executable  model,  or  it  may  be  used  to  create  a  physical  prototype  of  portions  of  the 
system  with  which  test  users  can  interact.  The  true  relevance  of  workload  lies  in  its 
impact  on  human  and  system  performance,  not  as  a  stand-alone  measure,  so  workload 
measures  should  be  easily  integrated  with  performance  models.  Similarly,  models  of 
human  performance  need  to  be  compatible  with  models  that  can  predict  overall  system 
performance.  The  goal  of  the  human  engineer  should  not  be  to  optimize  human 
performance  alone  but  to  put  human  performance  within  acceptable  levels  to  optimize 
overall  system  performance.  This  goal  cannot  be  accomplished  without  human  workload 
and  performance  models  that  are  compatible  with  higher-level  system  models.  Model 
compatibility  will  also  be  important  when  design  changes  are  made  that  necessitate 
alterations  to  the  models. 

IEEE  1220-1998:  6.5.11  -  Develop  models  and  fabricate  prototypes 

6.5.15  -  Final  design 

EIA-632:  Requirement  10  -  Progress  Against  Requirements 

Requirement  23  -  Tradeoff  Analysis 

Technical  Solution,  SP  1.2-2  -  Evolve  Operational  Concepts  and  Scenarios 
Technical  Solution,  SP  1.3-1  -  Select  Product  Component  Solutions 
Technical  Solution,  SP  2.1-1  -  Use  Effective  Design  Methods 
Technical  Solution,  SP  2.3-3  -  Design  Comprehensive  Interface 
Product  Integration,  SP  3.3-1  -  Checkout  Assembled  Product  Components 
Verification,  SP  1.1-1  -  Establish  a  Verification  Strategy 
Verification,  SP  1.2-2  -  Establish  the  Verification  Environment 
Verification,  SP  1.3-3  -  Establish  Detailed  Verification  Plans 
Verification,  SP  3.1-1  -  Perform  Verification 

Verification,  SP  3.2-2  -Analyze  Verification  Results  and  Identify  Corrective 
Action 

Verification,  SP  3.3-1  -  Perform  Reverification 
Validation,  SP  1.1-1  -  Establish  a  Validation  Strategy 
Validation,  SP  1.2-2  -  Establish  the  Validation  Environment 
Validation,  SP  1.3-3  -  Define  Detailed  Validation  Procedures 
Validation,  SP  2.1-1  -  Perform  Validation 
Validation,  SP  2.2-1  -  Capture  and  Analyze  Validation  Results 
DoD  5000.2-R:  C2.8.5.5  -  Human  Factors  Engineering 

C5.2.3.3  -  Design  Synthesis  and  Verification 
C5.2.3.5.2  -  Modeling  and  Simulation  (M&S) 

C5.2.3.5.9.1  -  Human  Factors  Engineering  (HFE) 

C5.2.3.5.9.3  -  Manpower  Initiatives 
SE  OSDs:  SE320  -  Evaluate  and  Select  Preferred  Architecture 
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3.7.2  Training  Concept  Evaluation 

The  resources  required  to  field  and  maintain  a  system  are  typically  key  concerns  of  the 
systems  engineer.  The  overall  cost  of  the  system  includes  the  cost  to  prepare  it  for  use 
and  to  maintain  it  over  its  life  cycle.  If  the  human  is  considered  to  be  part  of  the  system, 
then  the  selection  and  training  resources  required  to  prepare  and  provide  operators  and 
users  are  iust  as  relevant  as  the  manufacturing  resources  required  to  provide  hardware 
and  software.  The  users  and  operators  are  frequently  the  most  often  changed  and  vane 
parts  of  the  system.  The  training  required  to  prepare  them  for  use  of  the  system  andto 
maintain  their  qualifications  as  users  and  operators  are  important  parts  of  the  system  life 
cycle  support  requirements. 

In  the  development  of  a  particular  system,  training  may  or  may  not  be  considered  to  be 
nart  of  the  human  engineer’s  responsibilities.  Even  if  the  human  engineer  is  no  y 

responsible  for  developing  training  requirements  or  training  plans  and  methodologies, 
work  of  the  human  engineer  has  direct  and  significant  impact  on  these  issues.  The 
difference  between  the  knowledge,  skills,  and  abilities  required  to  be  a  system  user  and 
operator  and  the  knowledge,  skills,  and  abilities  possessed  by  prospective  users  and 
operators  will  determine  the  training  and  selection  requirements.  As  the  designer  of 
parts  of  the  system  with  which  the  human  operators  and  users  interact,  the  human 
engineer  has  a  direct  influence  on  the  training  requirements.  Additionall^huma 
interfaces  can  be  designed  to  provide  for  either  ease-of-use  or  ease-of-leaming.  It 
to  be  able  to  maximize  both  of  these  qualities,  and  their  relative  importance  will  influence 
the  design  of  tasks,  interfaces,  and  teams,  all  of  which  will  in  turn  influence  required 

training. 

As  the  human  tasks  and  interfaces  are  developed,  the  human  en§in®eir  must  be  °5 

constraints  on  training  and  selection.  The  knowledge,  skills,  and  abilities  expected  to  be 
available  in  prospective  users  and  operators  must  be  agreed  upon  by  the  hu™  ^neer 
and  systems  engineer.  Requirements  and  constraints  for  the  life  cycle  support  of  the 
system  must  be  available  to  the  human  engineer  to  ensure  that  the  training  and  selection 
requirements  are  compatible.  Requirements  such  as  those  for  on-the-job  training  o 
embedded  training  must  be  stated  early  to  reduce  the  likelihood  of  design  changes  to 
meet  these  requirements  at  a  later  date.  As  training  requirements  are  identified  and  a 
training  concept  emerges,  it  is  very  important  to  consider  the  overall  training  burden 
the  operators  and  users.  Training  for  a  particular  interface  feature,  for  example,  may 
seem  minimal,  but  when  all  such  requirements  are  added  up  for  that  individual,  t 
overall  training  load  can  be  quite  high.  Training  requirements  can  only  be  elimmated  at 
the  design  stage  -  design  problems  eventually  manifest  themselves  as  training  problems. 
From  a  fife  cycle  perspective,  the  additional  cost  in  the  design  stage  may  be  outweighed 
by  the  recurring  cost  of  continually  training  new  users. 


IEEE  1 220-1998:  6.1.2  -  Define  project  and  enterprise  constraints 

6.1.3  -  Define  external  constraints 
6.1.9  -  Define  life  cycle  process  concepts 
6.5.4 -Assess  life  cycle  quality  factors 
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EIA-632:  Requirement  21 -Transition  to  Use 

SE/SW  CMM:  Requirements  Development,  SP  1.1-1  -  Collect  Stakeholder  Needs 

Requirements  Development,  SP  1.1-2  —  Elicit  Needs 
Requirements  Development,  SP  1.2-1  -  Transform  Stakeholder  Needs, 
Expectations,  Constraints,  and  Interfaces  into  Customer  Requirements 
Requirements  Development,  SP  3.1-1  -  Establish  Operational  Concepts  and 

Scenarios  , 

Requirements  Development,  SP  3.4-3  -  Evaluate  Product  Cost,  Schedule,  and 

Risk 

Technical  Solution,  SP  1.2-2  -  Evolve  Operational  Concepts  and  Scenarios 
Technical  Solution,  SP  2.3-4  -  Perform  Make,  Buy,  or  Reuse  Analyses 
Technical  Solution,  SP  3.2-1  -  Establish  Product  Support  Documentation 
Product  Integration,  SP  1.1-1  -  Establish  a  Product  Integration  Strategy 
Product  Integration,  SP  1.2-2  -  Establish  the  Product  Integration  Environment 
Product  Integration,  SP  1.3-3  -  Define  Detailed  Product  Integration 
Procedures 

Product  Integration,  SP  3.3-1  -  Checkout  Assembled  Product  Components 

DoD  5000.2-R:  C2.8.5.2  -  Personnel 

C2.8.5.3  -  Training 

C2.8.5.5  -  Human  Factors  Engineering 
C5.2.3.3  -  Design  Synthesis  and  Verification 
C5. 2.3.5. 4.4  -  Support  Resources 
C5.2.3.5.9.1  -  Human  Factors  Engineering  (HFE) 

C5.2.3.5.9.4  -  Personnel  Initiatives 
C5.2.3.5.9.5  -Training 

SE  OSDs:  SE130  -  Identify  Constraints  and  Analyze  Operational  Requirements 


Once  estimates  of  subsystem  or  component  performance  are  available,  different  design 
alternatives  can  be  traded  off  to  determine  the  best  available  option.  If  multiple 
alternatives  meet  the  system’s  functional  and  performance  requirements,  then  those 
alternatives  should  be  compared  to  select  the  optimal  design.  Typically,  different  options 
will  have  different  strengths  and  weaknesses,  so  choosing  an  option  that  is  strong  m  one 
area  may  decrease  performance  in  other  areas.  For  this  reason  it  is  important  to  have 
already  determined  the  relative  importance  of  the  different  design  criteria  to  be  used.  A 
common  understanding  and  application  of  the  design  criteria  will  permit  better 
integration  of  the  results  of  human  engineering  analyses.  Even  if  a  formal  trade  study 
approach  is  not  employed,  the  definition  of  the  design  criteria  will  help  to  justify  the 
selections  and  make  it  easier  to  deal  with  subsequent  changes  to  system  design. 


Performing  tradeoffs  at  the  component  level  is  typically  a  simpler  task  than  doing  so  at 
higher  levels  of  system  design.  The  interactions  between  components  and  subsystems 
can  increase  drastically  as  higher-level  designs  are  considered.  Trade  studies  are 
typically  easier  to  perform  for  designers  who  are  only  responsible  for  a  single  subsystem 
or  feature  of  the  system.  The  same  group  of  people  may  have  performed  all  of  the  design 
work,  and  as  a  result  common  models  and  metrics  are  often  used.  Due  to  different 
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models,  techniques,  and  criteria  used  within  different  disciplines,  trade  studies  can  be 
more  difficult  for  the  systems  engineer  to  perform.  The  systems  engineer  has  to  in  egra  e 
the  different  models,  data,  and  criteria  that  have  been  employed  by  the  different 
disciplines  or  design  teams. 

In  some  cases,  a  tradeoff  may  involve  the  decision  of  whether  or  not  to  redesign  portions 
of  the  system  or  the  degree  of  redesign  required.  In  such  situations,  the  availability  o 
resources  such  as  time,  money,  and  personnel  become  as  important  as  technical 
feasibility.  The  systems  engineers  and  designers  within  different  disciplines,  such  as 
human  engineering,  must  operate  from  the  same  set  of  resource  assumptions  in  making 
these  decisions.  In  proposing  a  design  change,  the  human  engineer  should  not  simp  y 
state  that  there  is  a  problem  with  the  current  design,  but  a  potential  alternative  to  the 
current  design  should  also  be  provided.  This  alternative  should  be  in  line  with  the 
available  resources  and  the  selected  design  criteria  for  the  project  as  a  whole.  Simply 
because  the  human  engineer  has  the  time  and  resources  to  recommend  a  design  change 
does  not  mean  that  the  other  designers  required  to  implement  the  change  have  the 
available  resources.  The  human  engineering  feedback  must  be  adequately  prioritized  in 

order  for  it  to  be  useful. 


SE/SWCMM: 


IEEE  1220-1998:  6.7-  Systems  analysis 

6 .7.5  -  Define  trade-study  scope 

EIA-632:  Requirement  18  -  Physical  Solution  Representations 

Requirement  23  —  Tradeoff  Analysis 

Technical  Solution,  SP  1.3-1  -  Select  Product  Component  Solutions 
SE/SW  CMM:  Technical  Solution,  SP  2.2-1  -  Develop  a  Technical  Data  Package 

Technical  Solution,  SP  2.2-3  -  Establish  a  Complete  Technical  Data  Package 
Verification,  SP  2.1-1  -  Prepare  for  Peer  Reviews 
Verification,  SP  2.2-1  —  Conduct  Peer  Reviews 

Verification,  SP  2.3-2 -Analyze  Peer  Review  Data 

Verification,  SP  3.2-2  -Analyze  Verification  Results  and  Identify  Corrective 
Action 

DoD  5000.2-R:  Cl. 3.3  -  Cost/Schedule/Performance  Tradeoffs 

C3.4- Developmental  Test  and  Evaluation  (DT&E) 

C4.2  -  Analysis  of  Multiple  Concepts 
C5.2.3.4  -  System  Analysis  and  Control 
SE  OSDs:  SE320  -  Evaluate  and  Select  Preferred  Architecture 


DoD  5000.2-R: 


3.8  USER  AND  REQUIREMENTS  REVIEW 

Throughout  the  system  development  process,  the  system  design  must  be  reviewed  with 
respect  to  both  its  requirements  and  the  operational  need.  The  system  design  must  be 
compared  to  all  requirements,  not  simply  the  top-level  system  requirements.  Designers 
or  verifiers  within  individual  design  disciplines  must  carry  out  some  of  this  verification 
process.  The  conformance  or  nonconformance  of  the  system  design  to  its  requiremen  s 
must  be  reported  to  the  systems  engineer,  who  will  determine  the  appropriate  course  o 
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action  based  on  variables  such  as  system  performance  and  available  resources.  Sample 
inputs  and  products  related  to  User  and  Requirements  Review  are  shown  in  Table  3-11. 


Table  3-11.  Human  Engineering  Inputs  and  Products  in  User  and  Requirements  Reviews 


Inputs 

•  Simulations  and  prototypes 

•  User  interface  concepts  and  designs 

•  Crew  or  team  concepts  and  designs 

•  Concept  of  operations 

•  Mission  analyses 

•  Scenarios 

•  Human  roles 


Products 

•  Heuristic  usability  evaluation  results 

•  Usability  testing  analyses 

•  Human  performance  testing  results 

•  Human  performance  and  workload  estimates 
for  individual  tasks 

•  Concept  and  system  use  scenario  feedback 

•  User  interface  feedback 

•  Crew/team  feedback 


User  involvement  is  critical  in  producing  effective  and  usable  systems,  and  the  type  of 
involvement  is  important  as  well.  Subjective  feedback  from  users  and  subject  matter 
experts  is  appropriate  early  in  the  development  process,  but  it  must  be  augmented  with 
objective  performance  measures  as  designs  become  more  specific.  User  review^needs  to 
happen  early,  not  only  after  “all  the  bugs  have  been  worked  out  of  the  software.”  Too 
much  of  a  delay  in  user  review  reduces  the  possibility  of  being  able  to  impact  the  design. 
Rapid  prototyping  of  user  interfaces  should  be  employed,  and  reviews  should  not  be 
restricted  to  a  narrow  sample  of  the  expected  user  population.  Finally,  user  review  and 
human  performance  testing  will  be  inconsequential  if  appropriate  requirements  for  testing 
and  evaluation  were  not  previously  specified. 


3.8.1  Comparison  to  Human  Eireineering  Requirements 

As  system  designs  are  generated  from  requirements,  those  designs  must  then  be  verified 
to  ensure  that  the  requirements  are  satisfied.  This  verification  is  likely  to  be  at  least 
partially  included  in  the  responsibilities  of  designers  in  different  disciplines.  The 
originators  of  the  requirements,  the  individuals  who  created  the  design,  and  the  design 
verifiers  may  be  the  same  people  or  each  may  be  different. 

It  is  highly  probable  that  the  human  engineer  will  need  to  assess  and  ensure  that  designs 
generated  by  others  satisfy  human  engineering  requirements.  The  specific  human 
engineering  requirements,  such  as  design  requirements  and  human  performance 
requirements,  must  be  used  to  evaluate  the  designs.  This  evaluation  must  take  place  early 
enough  to  impact  the  designs,  not  only  once  the  physical  prototypes  have  been  built.  For 
a  typical  system,  a  large  amount  of  the  verification  process  may  be  spent  on  task  or  job 
designs  or  equipment  design  specific  to  human  engineering.  Other  designs,  however, 
will  have  to  be  reviewed  for  compatibility  with  human  engineering  requirements. 
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Verification  may  be  performed  through  a  variety  of  different  means,  ranging  from 
inspection  to  modeling  and  simulation  to  user-in-the-loop  testing. 

IEEE  1220-1998:  6.6.2  -  Conduct  verification  evaluation 

EIA-632:  Requirement  19  -  Specified  Requirements 

Requirement  20  -  Implementation 

Requirement  29  -  Logical  Solution  Representations  Validation 
Requirement  30  —  Design  Solution  Verification 
Requirement  31  —  End  Product  Verification 
SE/SW  CMM:  Technical  Solution,  SP  1.3-1  -  Select  Product  Component  Solutions 

Verification,  SP  1.1-1  -  Establish  a  Verification  Strategy 
Verification,  SP  1.2-2  -  Establish  the  Verification  Environment 
Verification,  SP  1.3-3  -  Establish  Detailed  Verification  Plans 

Verification,  SP 3.1-1 -Perform  Verification 

Verification,  SP  3.2-2  -  Analyze  Verification  Results  and  Identify  Corrective 
Action 

Verification,  SP  3.3-1  -  Perform  Reverification 

Validation,  SP  1.1-1  -  Establish  a  Validation  Strategy 

Validation,  SP  1.2-2  -  Establish  the  Validation  Environment 

Validation,  SP  1.3-3  -  Define  Detailed  Validation  Procedures 

Validation,  SP  2.1-1  -  Perform  Validation 

Validation,  SP  2.2-1  -  Capture  and  Analyze  Validation  Results 

DoD  5000.2-R:  C2.8.5  -  Human  Systems  Integration  (HSI) 

C2.8.6  —  Environment,  Safety,  and  Occupational  Health  ( to  Un ) 

Considerations 

C5.2.3.3  -  Design  Synthesis  and  Verification 
C5.2.3.5.9  -  Human  Systems  Integration  (HSI) 

C5.2.3.5.10  —  Environment,  Safety,  and  Occupational  Health  (ESOH) 

SE  OSDs:  SE310  -  Synthesize  Multiple  Physical  Architectures 


3.8.2  User  Review 

Verification  that  the  design  of  a  system  conforms  to  requirements  is  important,  but  the 
system  design  must  also  be  validated.  Precise  conformance  to  written  requirements  does 
not  always  provide  assurance  that  the  system  will  conform  to  the  needs  of  the  users, 
operators,  or  purchasers.  Reviewing  potential  designs  with  intended  users  and  operators 
through  means  such  as  storyboards,  simulations,  and  mockups  can  provide  early  and 
rapid  validation  feedback.  Feedback  from  representative  users  on  design  iterations 
should  be  sought  continually,  and  final  evaluation  of  the  design  must  include 
performance  testing  with  appropriate  users.  Without  such  analyses,  full  validation  t  a 
the  system  meets  the  operational  need  cannot  occur  until  the  system  is  operational  and 

fielded. 

One  of  the  major  roles  of  the  human  engineer  is  to  determine  the  requirements  and  needs 
of  the  intended  operators  and  users.  Although  reviewers  such  as  representative  users  and 
operators  or  subject  matter  experts  may  be  able  to  provide  some  feedback  or 
requirements  and  functional  descriptions,  more  effective  feedback  can  be  generated  from 
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the  review  of  proposed  physical  designs.  The  human  engineer  typically  has 
responsibility  for  human-in-the-loop  testing  and  user  reviews.  Through  system  use 
scenarios  and  static  or  dynamic  models  of  system  operation,  the  human  engineer  can 
elicit  feedback  that  may  be  used  for  changes  to  designs  or  requirements.  It  is  frequently 
useful  for  the  systems  engineers  and  other  designers  to  participate  in  or  observe  user 
testing.  Not  all  feedback  will  be  relevant  or  valid.  Changes  to  system  design  or 
requirements  should  be  based  on  an  objective  analysis  of  information,  not  on  the 
subjective  preferences  or  opinions  of  reviewers.  The  human  engineer  will  need  to 
evaluate  the  feedback  to  determine  what  changes  may  be  considered,  and  an  initial 
estimate  of  the  impact  of  those  changes  on  other  portions  of  the  system  should  be  made. 
This  information  will  need  to  be  passed  to  the  systems  engineers  or  other  designers. 

IEEE  1220-1998:  6.2.1  Compare  to  customer  expectations 

6.5.11  -  Develop  models  and  fabricate  prototypes 
6.6.2  -  Conduct  verification  evaluation 
EIA-632:  Requirement  10  -  Progress  Against  Requirements 

Requirement  11  —  Technical  Reviews 
Requirement  19  -  Specified  Requirements 
Requirement  20  -  Implementation 
Requirement  30  -  Design  Solution  Verification 
Requirement  31  -  End  Product  Verification 
Requirement  33  -  End  Products  Validation 
SE/SW  CMM:  Requirements  Development,  SP  1.1-2-  Elicit  Needs 

Requirements  Development,  SP  3.5-1  —  Validate  Requirements 
Requirements  Development,  SP  3.5-2  -  Validate  Requirements  with 
Comprehensive  Methods 

Technical  Solution,  SP  1.3-1  -  Select  Product  Component  Solutions 
Validation,  SP  1.1-1  -  Establish  a  Validation  Strategy 
Validation,  SP  1.2-2  -  Establish  the  Validation  Environment 
Validation,  SP  1.3-3  -  Define  Detailed  Validation  Procedures 
Validation,  SP  2.1-1  -  Perform  Validation 
Validation,  SP  2.2-1  -  Capture  and  Analyze  Validation  Results 
DoD  5000.2 -R:  C2.8.5.5  -  Human  Factors  Engineering 

C3.2.3.2  -  T&E  Guidelines 
C3.6  -  Operational  Test  &  Evaluation  (OT&Ej 
C5.2.3.3  -  Design  Synthesis  and  Verification 
C5.2.3.5.9.1  -  Human  Factors  Engineering  ( HFE ) 

SE  OSDs:  SE330  -  Integrate  System  Physical  Configuration 


3.8.3  Recommendation  of  Chan£es  to  Requirements  or  Designs 

Deficiencies  in  system  design  that  are  revealed  through  verification  or  validation  must  be 
addressed  by  some  combination  of  changes  to  the  design  and  to  requirements.  These 
changes  can  frequently  have  far-reaching  effects,  leading  to  time  delays  and  cost 
overruns.  It  is  the  role  of  the  systems  engineer  to  work  to  balance  the  required  changes 
with  the  available  resources  to  meet  the  design  goals.  This  requires  rapid  feedback  from 
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designers  within  various  disciplines  on  the  impact  of  changes.  The  systems  engineer 
must  consolidate  this  feedback  and  determine  the  best  course  of  action. 

The  human  engineer  should  go  beyond  singling  out  design  deficiencies  and  should  work 
to  present  alternative  designs  or  requirements.  No  matter  how  extensive  or  accurate 
human  engineering  analyses  may  be,  they  are  irrelevant  and  unusable  if  they  cannot  be 
translated  into  specific  design  solutions.  In  some  cases,  it  may  be  found  that  the 
operators  simply  cannot  meet  the  specified  human  performance  requirements  or  that 
unsatisfactory  workload  levels  exist.  This  will  necessitate  either  a  change  to  the 
requirements  or  an  addition  to  the  design  to  provide  additional  support.  Proposed  designs 
may  conflict  with  requirements  that  have  been  specified  by  the  human  engineer.  In  some 
instances,  other  designers  or  the  systems  engineer  may  want  to  delete  or  ignore  some 
derived  requirements  related  to  human  engineering.  The  human  engineer  must  know 
which  human  engineering  requirements  can  be  traded  away  to  efficiently  meet  overa 
system  requirements  and  which  requirements  cannot  be  sacnficed.  The  human  engineer 
should  not  blindly  hold  to  requirements  to  optimize  human  performance  when  the  overall 
performance  of  the  system  will  suffer. 

Once  deviations  from  requirements  are  noticed,  the  human  engineer  should  estimate  the 
impact  on  overall  system  performance  and  begin  to  develop  a  resolution  to  the  problem. 
Since  the  systems  engineering  will  be  responsible  for  resolving  conflicts  the  proposed 
changes  must  have  content  and  format  useful  to  the  systems  engineer.  The  format  of  the 
suggestions  should  be  identical  or  at  least  similar  to  that  of  suggestions  provided  by 
designers  in  other  disciplines.  The  content  of  the  suggestions  needs  to  be  sufficient  to 
provide  the  systems  engineer  with  a  description  of  the  changes,  the  rationale  for  the 
changes,  and  anticipated  impacts  on  the  remainder  of  the  system. 


EIA-632: 


IEEE  1220-1998:  6.7.1  -  Assess  requirement  conflicts 

6.7.3-  Assess  design  alternatives 
EIA-632:  Requirement  10  —  Progress  Against  Requirements 

Requirement  11-  Technical  Reviews 
Requirement  19  -  Specified  Requirements 
Requirement  23  -  Tradeoff  Analysis 

SE/SW  CMM:  Requirements  Management,  SP  1.3-1  -  Manage  Requirements  Changes 

Verification,  SP  3.2-2  -  Analyze  Verification  Results  and  Identify  Corrective 

Action 

Verification,  SP  3.3-1  -  Perform  Reverification 
Validation,  SP  2.2-1  -  Capture  and  Analyze  Validation  Results 
DoD  5000.2-R:  C2.8.5.5  -  Human  Factors  Engineering 

C5.2.3.4  -  System  Analysis  and  Control 
C5.2.3.5.9.1  -  Human  Factors  Engineering  (HFE) 

SE  OSDs:  SE330  -  Integrate  System  Physical  Configuration 


DoD  5000.2-R: 
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APPENDIX  A 

RELATIONSHIPS  BETWEEN  INTERACTIONS 
AND  SYSTEMS  ENGINEERING  PUBLICATIONS 
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The  following  tables  list  the  sections  of  this  technical  report  that  apply  to  individual  sections  of  various 
systems  engineering  publications.  For  Tables  A-l,  A-2,  A-3,  A-4,  and  A-6  the  relationships  listed 
correspondSto  those  provided  at  the  end  of  each  subsection  in  Section  3  of  this  technical  report. 

The  following  interactions  in  Table  A-5  are  based  on  the  “Information  for  Milestone  Reviews 
(DODI  5000.2)”  chart  that  is  included  as  Figure  1  in  the  current  Defense  Acquisition  anagemen 

Framework.  The  interactions  noted  in  the  paper  and  in  Appendix  A  bf ed  on  RoD  5000";'  ’ 
Mandatory  Pro^Hnres  for  Major  Defense  Acquisition  Programs  (MDAPs)  and  Maior  Automated 

Information  System  (MATS)  Acquisition  Programs. 


Table  A-l.  Interactions  Sorted  by  IEEE 

?  IEEE  1220-1998  Paragraph 

6.1.2  Define  project  and  enterprise  constraints 


16.1.3  Define  external  constraints 


6.1.4  Define  operational  scenarios _ 


6.1.7  Define  interfaces 


6.1.8  Define  utilization  environments 


6.1.9  Define  life  cycle  process  concepts 

6.1.1 1  Define  performance  requirements 

6.1.12  Define  modes  of  operations  ~ 


6.1.14  Define  design  characteristics 


6.1.15  Define  human  factors _ 


6.2.1  Compare  to  customer  expectations 

6.3.1  Functional  context  analysis _ 


6.3. 1.2  Define  functional  interfaces 


6.3.2  Functional  decomposition _ _ 


6.3.2.4  Define  data  and  control  flows 


6.3.3  Establish  functional  architecture _ 


6.4  Functional  verification  _ 


6.5.1  Group  and  allocate  functions 


6.5.2  Identify  design  solution  alternatives 


6.5.4  Assess  life  cycle  quality  factors 


>-1998 _  _  ^ 

Selection  of  Comparison  Systems 

Human  Engineering  Constraints  _ _ _ 

i  Development  of  Interface  and  Team  Concepts  or  Designs _ 

>  Training  Concept  Evaluation _ _ _ 

1  Selection  of  Comparison  Systems _ _ _ 

1  Human  Engineering  Constraints _ _ _ 

l  Selection  of  Human  Interface  and  Team  Guidelines _ _ 

I  Development  of  Interface  and  Team  Concepts  or  Designs _ 

1  Training  Concept  Evaluation  _ _ _ _ _ 

l  System  Use  Scenarios  _ _ _ _ _ _ 

1  Points  of  Human  Interface  _ _ _ _ 

3  Development  of  Interface  and  Team  Concepts  or  Designs _ 

3  User  Environment  Characteristics  and  Effects _ _ _ 

2  Training  Concept  Evaluation _ _ _ 

2  Human  Performance  Requirements  and  Human  Engineering  Design 

Requirements _ _ _ _ _ _ 

2  System  Use  Scenarios _ _ _ _ _ . _ - — 

2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements  _ _ _ _ _ 


1  Human  Engineering  Constraints _ _ _ 

2  User  Review _ _ _ _ _ 

1  Functional  Decomposition _ _ _ 

1  Points  of  Human  Interface  _ _ _ _ _ 

1  Functional  Decomposition  _ _ 

2  Selection  of  Human  Interface  and  Team  Guidelines _ 

3  Development  of  Interface  and  Team  Concepts  or  Designs _ 

2  Review  of  Functional  Architecture _ _ _ 


,2  Review  of  Functional  Architecture _ 

.2  Early  Identification  of  Mandatory  Allocations _ _ 

.3  Development  and  Approval  of  Function  Allocation 

Recommendations _ _ _ _ _ 

.1  Development  of  the  Task  List _ _ _ _ _ 

,2  Identification  of  Task  Characteristics,  Interactions,  and  Sequences 

.3  Selection  of  Modeling  Tools  and  Techniques  _ 

.2  Training  Concept  Evaluation 
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Table  A-l.  Interactions  Sorted  by  IEEE  1220-1998  (Continued) 


ii  IEEE  1220-1998  Paragraph 


^Interaction  Details  Paragraph 


6.5.5  Assess  technology  requirements 


3.4.1  Consideration  of  Human  Engineering  Technologies 


6.5.7  Define  physical  interfaces 


3.5.4  Task  and  Function  Audit 


3.6.1  Points  of  Human  Interface 


3.6.3  Development  of  Interface  and  Team  Concepts  or  Designs 


6.5.11  Develop  models  and  fabricate  prototypes 


3.4.1  Consideration  of  Human  Engineering  Technologies 


3.5.3  Selection  of  Modeling  Tools  and  Techniques 


3.7.1  Individual  and  Team  Workload  and  Performance  Estimation 


3.8.2  User  Review 


6.5.15  Final  design 


3.5.4  Task  and  Function  Audit 


3.7. 1  Individual  and  Team  Workload  and  Performance  Estimation 


6.6.2  Conduct  verification  evaluation 


3.8.1  Comparison  to  Human  Engineering  Requirements 


3.8.2  User  Review 


6.7  Systems  analysis 


3.7.3  Tradeoff  of  Concepts  and  Designs 


6.7.1  Assess  requirement  conflicts 


3.8.3  Recommendation  of  Changes  to  Requirements  or  Designs 


6.7.3  Assess  design  alternatives 


3.8.3  Recommendation  of  Changes  to  Requirements  or  Designs 


6.7.5  Define  trade-study  scope 


3.7.3  Tradeoff  of  Concepts  and  Designs 
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Table  A-2.  Interactions  Sorted  by  EIA  632 


-EiA-63i Interaction  Details 

Planning  Process 

D»/«.<iMAmont  A  PrnppQQ  Tmnlp.mentation 

3  1.1  Selection  of  Comparison  Systems 

3.1.2  Svstem  Use  Scenarios  _ _ _ 

oudicgy 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements  — _ — - 

Requirement  5  -  Technical  Effort  Definition 

3.2.1  Human  Engineering  Constraints 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements _  _ _ _ 

3  4  1  Consideration  of  Human  Engineering  Technologies 

3  5  3  Selection  of  Modeling  Tools  and  Techniques 

Assessment  Process 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements  _ _ _ . _ ■ 

Requirement  10  -  Progress  Against 
Requirements 

3  7  1  Individual  and  Team  Workload  and  Performance  Estimation 

3.8.2  User  Review _ _ _ _ 

3  8  3  Recommendation  of  Changes  to  Requirements  or  Designs 

Requirement  11  -  Technical  Reviews 

3.8.2  User  Review  _ _ _ _ _ 

3  8  3  Recommendation  of  Changes  to  Requirements  or  Designs 

Control  Process 

Requirement  13  -  Information 

Dissemination 

3.1.1  Selection  of  Comparison  Systems _ 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements _  _ _ _ _ _ — - 

3.5.3  Selection  of  Modeling  Tools  and  Techniques _ . 

Requirement  14  -  Acquirer  Requirements 

3.2.1  Human  Engineering  Constraints  _ _ _ 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements _ . _ _ _ _ 

Requirement  15  —  Other  Stakeholder 
Requirements 

3  2.1  Human  Engineering  Constraints 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements _ _ _ _ _ . _ 

Requirement  16  -  System  Technical 
Requirements 

3.1.2  System  Use  Scenarios _ _ _ 

3  1  3  User  Environment  Characteristics  and  Effects 

3.2.1  Human  Engineering  Constraints _ 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements _  _ _ _ _ 

3  4  1  Consideration  of  Human  Engineering  Technologies 

Requirement  17  -  Logical  Solution 
Representations 

3.3.1  Functional  Decomposition 

3  3.2  Review  of  Functional  Architecture 

3  4  2  Earlv  Identification  of  Mandatory  Allocations 

3.4.3  Development  and  Approval  of  Function  Allocation 

Recommendations  _ _ _ — 

3.5.1  Development  of  the  Task  List 

3  5  2  Identification  of  Task  Characteristics,  Interactions,  and  Sequences 

3,5.4  Task  and  Function  Audit _ _ _ 1 
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Table  A-2.  Interactions  Sorted  by  EIA  632  (Continued) 


<?:':;';SSf^'-EIA-632  Requirement  ■ 

.  V; Interaction  Details  Paragraph  •' 

Requirement  18  -  Physical  Solution 

3.4.2  Early  Identification  of  Mandatory  Allocations 

Representations 

3.4.3  Development  and  Approval  of  Function  Allocation 

Recommendations 

3.5.1  Development  of  the  Task  List 

3.5.2  Identification  of  Task  Characteristics,  Interactions,  and  Sequences 

3.5.4  Task  and  Function  Audit 

3.6.1  Points  of  Human  Interface 

3.6.2  Selection  of  Human  Interface  and  Team  Guidelines 

3.6.3  Development  of  Interface  and  Team  Concepts/Designs 

3.7.3  Tradeoff  of  Concepts  and  Designs 

Requirement  19  -  Specified  Requirements 

3.2.1  Human  Engineering  Constraints 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

3.8.1  Comparison  to  Human  Engineering  Requirements 

3.8.2  User  Review 

3.8.3  Recommendation  of  Changes  to  Requirements  or  Designs 

llmvlementation  Process  _ _ _ _ _ _ _ 

Requirement  20  -  Implementation 

3.8.1  Comparison  to  Human  Engineering  Requirements 

3.8.2  User  Review 

Transition  to  Use  Process  _ ... _ _ _ 

Requirement  21  -  Transition  to  Use  (3.7.2  Training  Concept  Evaluation 

Systems  Analysis  Process  _ _ _ _ _ 

Requirement  23  -  Tradeoff  Analysis 

3.5.3  Selection  of  Modeling  Tools  and  Techniques 

3  7  1  Individual  and  Team  Workload  and  Performance  Estimation 

3.7.3  Tradeoff  of  Concepts  and  Designs 

3.8.3  Recommendation  of  Changes  to  Requirements  or  Designs 

Requirement  24  -  Risk  Analysis 

3.1.2  System  Use  Scenarios  ( 

3.1.3  User  Environment  Characteristics  and  Effects 

\Reauirements  Validation  Process _ _ _ — - 

Requirement  25  -  Requirement  Statements 
Validation 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

Requirement  26  -  Acquirer  Requirements 
Validation 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

Requirement  27  -  Other  Stakeholder 
Requirements  Validation 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

Requirement  28  -  System  Technical 
Reauirements  Validation 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

Requirement  29  -  Logical  Solution 
Representations  Validation 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements _ _ _ _ _ 

3.8.1  Comparison  to  Human  Engineering  Requirements 

Lfv.vtem  Verification  Process  -  1 

Requirement  30  -  Design  Solution 
Verification 

3.8.1  Comparison  to  Human  Engineering  Requirements 

3.8.2  User  Review 

Requirement  31  -  End  Product  Verification 

3.8.1  Comparison  to  Human  Engineering  Requirements 

3.8.2  User  Review 

\End  Products  Validation  Process  _  — _ _ _ 

Requirement  33  -  End  Products  Validation 

3.8.1  Comparison  to  Human  Engineering  Requirements 

3.8.2  User  Review 
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Table  A-3.  Interactions  Sorted  by  SEI CMMI SE/SW  v  1.02,  Engineering  Process  Area 

W  CMMI  Goal  and  Practice  ^ Interaction Det^jsj^a 


Requirements  Management,  SG 1:  Manage  Requirements 


SP  1.1-1  -  Obtain  an  Understanding  of  - - - 

Rpmiirements  3.2.1  Human  Engineering  Constraints - - - ; — — — 

^  3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 

Requirements _  _ _ _ _ — 

— ci>  1  j  ?  _  nhtnin  rommitment  to  3.2.1  Human  Engineering  Constraints - - - . — __ — 

Requirements  3.2.2  Human  Performance  Requirements  and  Human  Engineenng  Design 

_ Requirements _ _ _ — - 

SP  13-1  -  Manage  Requirements  Changes  3.8.3  Recommendation  of  Changes  to  Requirements  or  Designs _ 

Development,  SG  1 :  Develop  Customer  Requirements  — 

SP  1 1-1  -  Collect  Stakeholder  Needs  3.1.2  System  Use  Scenarios - - - - 

3.2.1  Human  Engineering  Constraints _ _ _ _ _ . - ; — 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 

Requirements _ _ _ 

3.7.2  Training  Concept  Evaluation _ _ _ _ _ 

SP  1.1-2 -Elicit  Needs-  3.1.2  System  Use  Scenarios - _ - - - 

3.2.1  Human  Engineering  Constraints  _ _ _ _ _ ; — 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 

_ Requirements - - - - - . - - 

3.7.2  Training  Concept  Evaluation _ _ _ 

_ 3,8.2  User  Review _ _ _ . _ _ _ 

SP  1.2-1  -  Transform  Stakeholder  Needs,  3.1.2  System  Use  Scenarios - - - - - 

Fxnectations  Constraints,  and  Interfaces  into  3.2.1  Human  Engineering  Constraints -  — - ; — — 

SSTSSS-  3.2.2  Human  Perform^  Requirements  and  Human  Engmeenng  Des,gn 

_ Requirements _ _ _ _ _ _ _ .... 

3.7.2  Training  Concept  Evaluation _ _ _ _ _ _ 

^nuirrments  Development,  SG  2:  Develop  Product  Requirements  — - 

«p  it  i_  Fstahlish  Product  and  Product  3.2.1  Human  Engineenng  Constraints  . — 

Component  Requirements  3.2.2  Human  Performance  Requirements  and  Human  Engineenng  esign 

_ Requirements _ _ _ _ _ . — . - 

3.6.2  Selection  of  Human  Interface  and  Team  Guidelines - 

SP  2.2-1  -  Allocate  Product  Compo^  3.4.2  Early  Identification  of  Mandatory  ^loca^s  — - 

Requirements  3-4-3  Development  and  Approval  of  Function  Allocation 

Recommendations _ _ _ ; - ; — — — : — 

SP  2.3-1  -  Identify  Interface  Requirement"  3.2.2  Human  Performance  Requirements  and  Human  Engineenng  Design 

_ Requirements - - - - - — 

3,4,1  Consideration  of  Human  Engineering  Technologies - - 

_ 3,6.1  Points  of  Human  Interface _ _ _ _ 

Requirements  Development.  SG  3:  Analyze  andVaHdate  Requirements^ - - - - 

SP  3  1-1  —  Establish  Operational  Concepts  3.1.2  System  Use  Scenanos -  — - 

and  Scenarios _ 3.7.2  Training  Concept  Evaluation - - - 

Sp  2  2  1  «  rv»finitir>n  nf  Required  3.3.1  Functional  Decomposition - - - - - 

Functionality _ _ _ 13.3.2  Review  of  Functional  Architecture - - 


SP  1.1-2  -  Elicit  Needs 


3.1.1  Selection  of  Comparison  Systems 


SP  1.2-1  -  Transform  Stakeholder  Needs, 


SP  2.2-1  -  Allocate  Product  Component 
Requirements 

SP  2.3-1  -  Identify  Interface  Requirements 
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Table  A-3.  Interactions  Sorted  by  SEI CMMI  SE/SW  v  1.02,  Engineering  Process  Area  (Continued) 


CMMI  Goal  and  Practice  *  - 

Interaction  Details  Paraeraph'^'i?f'^^W^v';-': 

SP  33-1  -  Analyze  Requirements 

3.2. 1  Human  Engineering  Constraints 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

SP  3.4-3  -  Evaluate  Product  Cost,  Schedule, 
and  Risk 

3.4.1  Consideration  of  Human  Engineering  Technologies 

3.7.2  Training  Concept  Evaluation 

SP  3.5-1  -  Validate  Requirements 

3.1.3  User  Environment  Characteristics  and  Effects 

3.2.1  Human  Engineering  Constraints 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

3.8.2  User  Review 

SP  3.5-2  -  Validate  Requirements  with 
Comprehensive  Methods 

3.1.2  System  Use  Scenarios 

3.2.1  Human  Engineering  Constraints 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

3.8.2  User  Review 

{Technical  Solution .  SG  1:  Select  Product  Component  Solutions  - 

SP  1.1-1  -  Develop  Alternative  Solutions  and 
Selection  Criteria 

3.1.1  Selection  of  Comparison  Systems 

3.4.2  Early  Identification  of  Mandatory  Allocations 

3.4.3  Development  and  Approval  of  Function  Allocation 

Recommendations 

3.6.3  Development  of  Interface  and  Team  Concepts/Designs 

SP  1.1-2  -  Develop  Detailed  Alternative 
Solutions  and  Selection  Criteria 

3.1.2  System  Use  Scenarios  _ 

3.4.1  Consideration  of  Human  Engineering  Technologies 

3.4.2  Early  Identification  of  Mandatory  Allocations 

3.4.3  Development  and  Approval  of  Function  Allocation 

Recommendations 

3.5.1  Development  of  the  Task  List 

3.6.3  Development  of  Interface  and  Team  Concepts/Designs  | 

SP  1.2-2  -  Evolve  Operational  Concepts  and 
Scenarios 

3.1.2  System  Use  Scenarios 

3.1.3  User  Environment  Characteristics  and  Effects 

3.5.1  Development  of  the  Task  List 

3.5.2  Identification  of  Task  Characteristics,  Interactions,  and  Sequences 

3.7.1  Individual  and  Team  Workload  and  Performance  Estimation 

3.7.2  Training  Concept  Evaluation 

SP  1.3-1  -  Select  Product  Component 
Solutions 

3.4. 1  Consideration  of  Human  Engineering  Technologies 

3.4.2  Early  Identification  of  Mandatory  Allocations 

3.4.3  Development  and  Approval  of  Function  Allocation 

Recommendations 

3.7.1  Individual  and  Team  Workload  and  Performance  Estimation 

3.7.3  Tradeoff  of  Concepts  and  Designs 

3.8.1  Comparison  to  Human  Engineering  Requirements 

3.8.2  User  Review 

\Technical  Solution ,  SG  2:  Develop  the  Design _ _ _ 

SP  2.1-1  -  Use  Effective  Design  Methods 

3.5.3  Selection  of  Modeling  Tools  and  Techniques 

3.5.4  Task  and  Function  Audit 

3.6.2  Selection  of  Human  Interface  and  Team  Guidelines 

3.7.1  Individual  and  Team  Workload  and  Performance  Estimation 
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Table  A-3.  Interactions  Sorted  by  SEI CMMI SE/SW  v  1 .02,  Engineering  Process  Area  (Continued) 


SP  2.2-3  -  Establish  a  Complete  Technical 
Data  Package 


'  i  ;  •  "ttMiyil  Gd>t  and  Practice  |  InteracttonDe^^ 

pP  -  De’elop  a  Technical  Data  ||i  topiiremenls  and  Human  Engineering  Design 

FaC  agC  Requirements _ - _ 

3.6.3  Development  of  Interface  and  Team  Concepts/Designs - 

3.7.3  Tradeoff  of  Concepts  and  Designs _ _ _ ■ 

SP  2.2-3  -  Establish  a  Complete  Technical  3.1.2  System  Use  Scenario^ -  - — - 

n„t„  packaee  3.2.1  Human  Engineering  Constraints - - - : — — — 

Data  Package  3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 

_ Requirements  - - - - - - - 

3.5.1  Development  of  the  Task  List _ _ _ . _ 

3.5.2  Identification  of  Task  Characteristics,  Interactions,  and  Sequences  _ 

3.6.3  Development  of  Interface  and  Team  Concepts/Designs - - 

3  7  3  Tradeoff  of  Concepts  and  Designs _ _ _ 

-  -T  ;  .  ,  n...Hn,io—  3.4.1  Consideration  of  Homan  Engineer!.,,.  Technologies - 

3,6.1  Points  of  Human  Interface _ _ _ 

3.6.3  Development  of  Interface  and  Team  Concepts/Designs - . 

cp  2  3-3  -  Desien  Comprehensive  Interface  3.6.1  Points  of  Human  Interface - _ —  - — — ; — -  - 

g  3  6  3  Development  of  Interface  and  Team  Concepts/Designs - 

3  7  1  Individual  and  Team  Workload  and  Performance  Estimation - 

:r~-  •  nr  Reuse  3A 1  Consideration  of  Human  Engineering  Technologies - 

_ _ 13.7.2  Training  Concept  Evaluation^ - - - 

"“ps*- 1  ^  **■--  = 

SP  3,2.1  _  Establish  Product  Support  3.7 .2  Training  Concept  Evaluation 

Documentation _ _ — - - 

Product  Integration,  SG  i:  Prepare  (or  Product-Integration  - -  — — — - ’ 

SP  1 1-1  -  Establish  a  Product  Integration  3.2.1  Human  Engineering  Constraints - - - - - 

s  •  v  _  3.7.2  Training  Concept  Evaluation  - - - - - 

SP  1  2-2  -  Establish  the  Product  Integral"  3.1.3  User  Environment  Characteristics  and  Effects - 

Environment _ 3.7.2  Training  Concept  Eva  nation - - - - 

SP  1.3-3  -  Define  Detailed  Product  3.7.2  Training  Concept  Evaluation  _ 

Integration  Procedures  _  J - — — - — - -  “ 

of  lnterface  and  Team  ConcePts/uesign^ 

_  ~T  f.  .  c/-r  j.  4  <.r»*r,hio  Pmiturt  Cnmnonents  and  Deliver  the  Product  — 

Product  Integration,  SG  3.  Assemtne  rr£au -  P  ,:'7.  ■ .  ,  T.^  WnrUnnH  and  Performance  Estimation 


SP  2.3-1  -  Establish  Interface  Descriptions 
SP  2.3-3  -  Design  Comprehensive  Interface 


SP  2.3-4 

Analyses 


■  Perform  Make,  Buy,  or  Reuse 


SP  3.3-1  -  Checkout  Assembled  Product 

Components _ 

Verification,  SG  J:  Prepare  for  Verification 
SP  1.1-1  -  Establish  a  Verification  Strategy 


,  UfnfSVilKim  wtw  - —  -  — — 

3.7.1  Individual  and  Team  Workload  and  Performance  Estimation 

3.7.2  Training  Concept  Evaluation _ _ _ 

3.1.3  User  Environment  Characteristics  and  Effects  - 

3.5.3  Selection  of  Modeling  Tools  and  Techniques _ _ _ 

3,6.2  Selection  of  Human  Interface  and  Team  Guidelines - 

3.7.1  Individual  and  Team  Workload  and  Performance  Estimation 

3.8.1  Comparison  to  Human  Engineering  Requirements  - 
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Table  A-3.  Interactions  Sorted  by  SEI CMMI SE/SW  v  1.02,  Engineering  Process  Area  (Continued) 


s  V ;  CMMI  Goal  and  Practice 

Interaction  Details  Paragrapl»iffeS3ftl^#^;?:i;  ; 

SP  1  2-2  -  Establish  the  Verification 

3.1.2  System  Use  Scenarios 

Environment 

1.3  User  Environment  Characteristics  and  Effects 

3.5.3  Selection  of  Modeling  Tools  and  Techniques 

7  1  Individual  and  Team  Workload  and  Performance  Estimation 

3  8.1  Comparison  to  Human  Engineering  Requirements 

SP  13-3  -  Establish  Detailed  Verification 

7  1  Individual  and  Team  Workload  and  Performance  Estimation 

Plans 

3  8.1  Comparison  to  Human  Engineering  Requirements 

1  Vorifirntinn  SG  2:  Perform  Peer  Reviews  _ _ _ 1 

SP  2  1-1  -  Prepare  for  Peer  Reviews 

3  3  2  Review  of  Functional  Architecture 

3.5.4  Task  and  Function  Audit 

3.7.3  Tradeoff  of  Concepts  and  Designs 

SP  2.2-1  -  Conduct  Peer  Reviews 

3.3.2  Review  of  Functional  Architecture _ _ _ 

3.5.4  Task  and  Function  Audit 

3.7.3  Tradeoff  of  Concepts  and  Designs _ _ _ 

SP  23-2  -  Analyze  Peer  Review  Data 

3  3.2  Review  of  Functional  Architecture 

3.5.4  Task  and  Function  Audit _ _ _ 

3.7.3  Tradeoff  of  Concepts  and  Designs 

1  Verification.  SG  3:  Verify  Selected  Work  Products - - - - - - 

SP  3.1-1  -  Perform  Verification 

3.5.4  Task  and  Function  Audit 

3  7  1  Individual  and  Team  Workload  and  Performance  Estimation 

3.8. 1  Comparison  to  Human  Engineering  Requirements 

SP  3.2-2  -  Analyze  Verification  Results  and 
Identify  Corrective  Action 

3  7  1  Individual  and  Team  Workload  and  Performance  Estimation 

3.7.3  Tradeoff  of  Concepts  and  Designs 

3.8.1  Comparison  to  Human  Engineering  Requirements 

3  8  3  Recommendation  of  Changes  to  Requirements  or  Designs 

SP  33-1  -  Perform  Reverification 

3  7  1  Individual  and  Team  Workload  and  Performance  Estimation  | 

3  8.1  Comparison  to  Human  Engineering  Requirements 

3.8.3  Recommendation  of  Changes  to  Requirements  or  Designs 

\vnlMatinn.  SG  1:  Preoare  for  Validation  - - — - - - — 1 

SP  1.1-1  -  Establish  a  Validation  Strategy 

3.1.3  User  Environment  Characteristics  and  Effects 

3.5.3  Selection  of  Modeling  Tools  and  Techniques 

3  6  2  Selection  of  Human  Interface  and  Team  Guidelines 

3  7  1  Individual  and  Team  Workload  and  Performance  Estimation 

3.8.1  Comparison  to  Human  Engineering  Requirements 

3.8.2  User  Review 

SP  1.2-2  -  Establish  the  Validation 
Environment 

3.1.2  System  Use  Scenarios 

3  1.3  User  Environment  Characteristics  and  Effects 

3  7  1  Individual  and  Team  Workload  and  Performance  Estimation 

3.8.1  Comparison  to  Human  Engineering  Requirements 

3.8.2  User  Review 

SP  13-3  -  Define  Detailed  Validation 
Procedures 

3  7  1  Individual  and  Team  Workload  and  Performance  Estimation 

3.8.1  Comparison  to  Human  Engineering  Requirements 

3.8.2  User  Review 
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Table  A-3.  Interactions  Sorted  by  SEI CMMI SE/SW  v  1.02,  Engineering  Process  Area  (Continued) 

■  CMMI  Goal  and  Practice  1  Interaction  Details  Paragraph^  — 

Validation,  SG  2:  Validate.  Product  or  Product  Ctfmponiwfc  . ,  „  . ,  - 


SP  2.1-1  -  Perform  Validation 


SP  2.2-1  -  Capture  and  Analyze  Validation 
Results 


^ - 

'  3,7.1  Individual  and  Team  Workload  and  Performance  Estimation 

3.8.1  Comparison  to  Human  Engineering  Requirements _ 

3.8.2  User  Review _ _ _ _ _ — _ 

'  3.7.1  Individual  and  Team  Workload  and  Performance  Estimation 

3.8.1  Comparison  to  Human  Engineering  Requirements _ 

3.8.2  User  Review _ _ _ _ _ 

3.8.3  Recommendation  of  Changes  to  Requirements  or  Designs 


NSWCDD/TR-01/101 


Table  A-4.  Interactions  Sorted  by  DoD  5000.2-R  (June  2001) 


Sfe-DoD 5000.2-R ■■  ■' 

'  Interaction  Details  Paragraph.^ 

Cl. 2  Thresholds  and  Objectives 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

Cl. 3.3  Cost/Schedule/Performance  Tradeoffs 

3.7.3  Tradeoff  of  Concepts  and  Designs 

Cl. 4  Acquisition  Program  Baseline  (APB) 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

C2.2  Requirements 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

C2.7.2  Interoperability 

3.2.1  Human  Engineering  Constraints 

C2.8.5  Human  Systems  Integration  (HSI) 

3.2.1  Human  Engineering  Constraints 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

3.8.1  Comparison  to  Human  Engineering  Requirements 

C2.8.5.2  Personnel 

3.7.2  Training  Concept  Evaluation 

C2.8.5.3  Training 

3.7.2  Training  Concept  Evaluation 

C2.8.5.4  Personnel  Survivability  and 

Habitability 

3.1.3  User  Environment  Characteristics  and  Effects  j 

3.3.2  Review  of  Functional  Architecture 

C2.8.5.5  Human  Factors  Engineering 

3.1.2  System  Use  Scenarios 

3.1.3  User  Environment  Characteristics  and  Effects 

3.4. 1  Consideration  of  Human  Engineering  Technologies 

3.4.2  Early  Identification  of  Mandatory  Allocations 

3.4.3  Development  and  Approval  of  Function  Allocation 

Recommendations 

3.6.1  Points  of  Human  Interface 

3.6.2  Selection  of  Human  Interface  and  Team  Guidelines 

3.6.3  Development  of  Interface  and  Team  Concepts  or  Designs 

3.7.1  Individual  and  Team  Workload  and  Performance  Estimation 

3.7.2  Training  Concept  Evaluation 

3.8.2  User  Review 

3.8.3  Recommendation  of  Changes  to  Requirements  or  Designs 

C2.8.6  Environment,  Safety,  and  Occupational 
Health  (ESOH)  Considerations 

3.1.3  User  Environment  Characteristics  and  Effects 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

3.8.1  Comparison  to  Human  Engineering  Requirements 

C3.2.3.2  T&E  Guidelines 

3.1.2  System  Use  Scenarios 

3.8.2  User  Review 

C3.4  Developmental  Test  and  Evaluation 
(DT&E) 

3.4.1  Consideration  of  Human  Engineering  Technologies 

3.7.3  Tradeoff  of  Concepts  and  Designs 

C3.6  Operational  Test  &  Evaluation  (OT&E) 

3.8.2  User  Review 

C4.2  Analysis  of  Multiple  Concepts 

3.7.3  Tradeoff  of  Concepts  and  Designs 

C4.4  Affordability 

3.2.1  Human  Engineering  Constraints 

C4.5.4  Manpower 

3.2. 1  Human  Engineering  Constraints 
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Table  A-4.  Interactions  Sorted  by  DoD 

C5.2  Systems  Engineering 


C5.2.3.1  Requirements  Analysis 
C5.2.3.2  Functional  Analysis/ Allocation 


C5.2.3.3  Design  Synthesis  and  Verification 


C5.2.3.4  System  Analysis  and  Control 

C5.2.3.5.2  Modeling  and  Simulation  (M&S) 
C5-2.3.5.2.3  Planning  the  M&S  Approach 

C5.2.3.5.2.4  M&S  Standards _ 

C5-2.3.5.2.6  M&S  Support  of  SB  A 

C5.2.3.5.4.4  Support  Resources _ 

C5.2.3.5.5  Open  Systems  Design 

C5.2.3.5.9  Human  Systems  Integration  (HSI) 


C5.2.3.5.9.1  Human  Factors  Engineering  (HFE) 


5000.2-R  (Continued)  _ _ 

~  3.1.1  Selection  of  Comparison  Systems _ _ _ 

3.5.4  Task  and  Function  Audit  _ _ _ 

3.6. 1  Points  of  Human  Interface _ _ _ _ _ 

~  3.2.1  Human  Engineering  Constraints _ 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 

_ Requirements _ _ _ 

~  3.3.1  Functional  Decomposition _  , _ 

3.3.2  Review  of  Functional  Architecture _ _ _ 

3.4.2.  Early  Identification  of  Mandatory  Allocations _ 

3.4.3  Development  and  Approval  of  Function  Allocation 

Recommendations  _ _ _ — - - 

“  3.6.3  Development  of  Interface  and  Team  Concepts  or  Designs _ . 

3.7. 1  Individual  and  Team  Workload  and  Performance  Estimation 

3.7.2  Training  Concept  Evaluation _ _ _ _ _ 

3.8.1  Comparison  to  Human  Engineering  Requirements _ _ 

3.8.2  User  Review _ _ _ _ _ _ _ 

—  3.7.3  Tradeoff  of  Concepts  and  Designs _ _ _ _ _ 

3.8.3  Recommendation  of  Changes  to  Requirements  or  Designs _ 

—  3.7.1  Individual  and  Team  Workload  and  Performance  Estimation _ 

—  3.5.3  Selection  of  Modeling  Tools  and  Techniques _ _ _ 

_  3.5.3  Selection  of  Modeling  Tools  and  Techniques _ . 

~  3.1.2  System  Use  Scenarios _ _ _ 

~  3.7.2  Training  Concept  Evaluation _ _ _ 

—  3.6.1  Points  of  Human  Interface _ _ _ _ _ 

3.6.2  Selection  of  Human  Interface  and  Team  Guidelines  _ 

~  3.2.1  Human  Engineering  Constraints  _ __ _ _ _ _ — 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 

_ Requirements _ _ _ _ _ _ _ 

3.8.1  Comparison  to  Human  Engineering  Requirements  _ 

[)"  3.1.2  System  Use  Scenarios  _ _ _ 

3.1.3  User  Environment  Characteristics  and  Effects  _ 

3.4.1  Consideration  of  Human  Engineering  Technologies _ 

3.4.2  Early  Identification  of  Mandatory  Allocations  _ 

3.4.3  Development  and  Approval  of  Function  Allocation 

_ Recommendations _ _ _ _ 

3.5.1  Development  of  the  Task  List _ _ _ 

3.5.2  Identification  of  Task  Characteristics,  Interactions,  and  Sequences 

3.6.1  Points  of  Human  Interface _ _ _ 

3.6.2  Selection  of  Human  Interface  and  Team  Guidelines _ 

3.6.3  Development  of  Interface  and  Team  Concepts  or  Designs _ 

3.7.1  Individual  and  Team  Workload  and  Performance  Estimation 

3.7.2  Training  Concept  Evaluation _ _ _ 

3.8.2  User  Review _ _ _ _ _ _ _ 

3.8.3  Recommendation  of  Changes  to  Requirements  or  Designs _ 
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Table  A-4.  Interactions  Sorted  by  DoD  5000.2-R  (Final  Coordination  Draft)  (Continued) 


:DoD  5000 J-R  V  .  :‘.r ' ,v  • 

;  Interaction  Details  Paragraplt^i^^jpc^s#:1;:;  .• 

C5.2.3.5.9.2  Habitability  and  Personnel 
Survivability 

3.1.3  User  Environment  Characteristics  and  Effects 

3.3.2  Review  of  Functional  Architecture 

C5.2.3.5.9.3  Manpower  Initiatives 

3.7.1  Individual  and  Team  Workload  and  Performance  Estimation 

C5.2.3.5.9.4  Personnel  Initiatives 

3.7.2  Training  Concept  Evaluation 

C5.2.3.5.9.5  Training 

3.7.2  Training  Concept  Evaluation 

C5.2.3.5.10  Environment,  Safety,  and 
Occupational  Health  (ESOH) 

3.1.3  User  Environment  Characteristics  and  Effects 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

3.8.1  Comparison  to  Human  Engineering  Requirements 

C7.5  Technology  Maturity 

3.4.1  Consideration  of  Human  Engineering  Technologies 
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Table  A-5.  Interactions  Sorted  by  Products  from  DoD  5000.2 


.  -DoD 5000*2  Products  ■  '  ' 

^Interaction  Details  Paragrap|»;^*3^»*l«-  - 

Acquisition  Program  Baseline 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

Acquisition  Strategy 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements  _ _ _ 

3  4  1  Consideration  of  Human  Engineenng  Technologies 

Affordability  Assessment 

3.2.1  Human  Engineering  Constraints 

Analysis  of  Alternatives 

3  7  3  Tradeoff  of  Concepts  and  Designs 

Beyond  Low  Rate  Initial  Production  (LRIP) 
Rp.nnrt 

3.8.1  Comparison  to  Human  Engineering  Requirements 

Independent  Technology  Assessment 

3  4  1  Consideration  of  Human  Engineering  Lechnologies 

Live  Fire  T&E  Report 

3  8  1  Comparison  to  Human  Engineering  Requirements 

Manpower  Estimate 

3  6  3  Development  of  Human  Interface  and  1  earn  Concepts  or  Designs 

i  7  ^  Individual  and  Team  Workload  and  Performance  Estimation 

Market  Research 

3  4  1  Consideration  of  Human  Engineering  lechnologies 

Mission  Need  Statement 

3.1.2  System  Use  Scenarios 

Operational  Requirements  Document 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

3  8  1  Comparison  to  Human  Engineering  Requirements 

Operational  Test  &  Evaluation  (OT&E)  Results 

3  8  1  Comparison  to  Human  Engineering  Requirements 

3.8.2  User  Review  . 

Postdeployment  Performance  Review 

3  8  1  Comparison  to  Human  Engineering  Requirements 

3.8.2  User  Review 

Test  &  Evaluation  Master  Plan 

3.1.2  System  Use  Scenarios 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

3  5  3  Selection  of  Modeling  Tools  and  Techniques 

3  8  1  Comparison  to  Human  Engineering  Requirements 

3.8.2  User  Review 
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Table  A-6.  Interactions  Sorted  by  Systems  Engineering  OSDs 


Systems  Engineering  OSD 

Interaction  Details  Paragraph  ^ 

SE1 10  -  Define  and  Assess  Operational 
Environment 

3.1.1  Selection  of  Comparison  Systems 

3.1.2  System  Use  Scenarios 

3.1.3  User  Environment  Characteristics  and  Effects 

SE130  -  Identify  Constraints  and  Analyze 
Operational  Requirements 

3.2. 1  Human  Engineering  Constraints 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

3.6.2  Selection  of  Human  Interface  and  Team  Guidelines 

3.6.3  Development  of  Interface  and  Team  Concepts  or  Designs 

3.7.2  Training  Concept  Evaluation 

SE140  -  Identify  Functional  and  Performance 
Requirements 

3.2.2  Human  Performance  Requirements  and  Human  Engineering  Design 
Requirements 

SE210  -  Functional  Definition 

3.3.1  Functional  Decomposition 

3.3.2  Review  of  Functional  Architecture 

3.6. 1  Points  of  Human  Interface 

SE310  -  Synthesize  Multiple  Physical 
Architectures 

3.4.1  Consideration  of  Human  Engineering  Technologies 

3.4.2  Early  Identification  of  Mandatory  Allocations 

3.4.3  Development  and  Approval  of  Function  Allocation 
Recommendations 

3.8.1  Comparison  to  Human  Engineering  Requirements 

SE320  -  Evaluate  and  Select  Preferred 
Architecture 

3.5.1  Development  of  the  Task  List 

3.5.2  Identification  of  Task  Characteristics,  Interactions,  and  Sequences 

3.5.3  Selection  of  Modeling  Tools  and  Techniques 

3.5.4  Task  and  Function  Audit 

3.6.1  Points  of  Human  Interface 

3.7.1  Individual  and  Team  Workload  and  Performance  Estimation 

3.7.3  Tradeoff  of  Concepts  and  Designs 

SE330  -  Integrate  System  Physical 

Configuration 

3.5.3  Selection  of  Modeling  Tools  and  Techniques 

3.8.2  User  Review 

3.8.3  Recommendation  of  Changes  to  Requirements  or  Designs 

Note:  Systems  Engineering  and  Human  Engineering  operational  sequence  diagrams  are  available  at 
http://www.manningaffordabilitv.com.  URLs  for  direct  access  are: 

SE  OSDs:  http://www.manningaffordabilitv.com/S&tweb/PUBS/SE  _HE/SE  OSD.pdf 
HE  OSDs:  http://www.manningaffordabilitv.com/S&tweb/PUBS/SE_HE/HE  OSD.pdf 
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APPENDIX  B 

SUGGESTED  REFERENCES 
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The  following  references  each  provide  further  information  on  human  engineering  or 
human  factors,  primarily  in  the  context  of  systems  engineering. 

Human  Factors  in  Systems  Engineering;  Alphonse  Chapanis;  1996  (340  pages). 

Part  of  a  series  of  titles  on  systems  engineering,  this  book  covers  the  integration  of  human 
factors  into  the  development  of  tools,  machines,  and  systems.  It  includes  sections  on 
systems  engineering  and  systems  engineering  work  products  along  with  human  factors 
methods.  General  introductions  to  human  physical  and  mental  characteristics  and 
personnel  selection  and  training  issues  are  also  included.  The  conclusion  of  the  book 
covers  the  specification  of  human-system  requirements  and  how  to  make  tradeoffs 
between  competing  requirements  or  designs. 

MANPRINT:  An  Approach  to  Systems  Integration;  Harold  Booher,  Ed.;  1990 

(600  pages).  ,  .  „  .. 

This  book  is  a  collection  of  chapters  by  various  authors  on  topics  relating  to  the 

Manpower  and  Personnel  Integration  (MANPRINT)  program  developed  for  the 
U  S  Army.  Management,  design,  and  integration  topics  are  included.  Although  sections 
such  as  those  on  design  tools  lack  up-to-date  information,  the  discussion  of  the  principles 
of  human  engineering  and  integration  remains  relevant. 

Introduction  to  Human  Factors  Engineering;  Christopher  Wickens,  Sallie  Gordon,  and 

Yili  Liu;  1997  (750  pages).  .  .  .  , 

Although  there  is  an  emphasis  on  cognition  and  human  information  processing,  this  book; 
provides  a  broad  coverage  of  human  factors  issues.  Topics  include  automation,  human- 
computer  interaction,  safety,  and  workplace  layout. 

Human  Factors  in  Engineering  and  Design  (7th  ed.);  Mark  Sanders  and  Ernest 

McCormick;  1993  (790  pages).  ,  , 

First  published  in  1957,  this  book  is  commonly  used  as  an  upper-undergraduate  level  or 
introductory  graduate  level  textbook.  It  provides  a  broad  overview  of  human  factors  and 
ergonomics  topics  and  sections  on  how  human  factors  should  be  applied.  Other  sections 
include  information  input,  human  output  and  control,  workplace  design,  and 
environmental  conditions.  Information  included  on  human-computer  interaction  is 
relatively  dated,  but  the  principles  illustrated  by  the  examples  included  remain  applicable. 

Homan  Performance  Engineering  (3rd  ed.);  Robert  Bailey;  1996  (576  pages). 

Although  sometimes  billed  as  a  general  human  factors  reference,  this  book  places 
significant  emphasis  on  computer-based  systems.  There  is  more  of  a  discussion  on 
human  factors  techniques  and  methodologies  than  in  other  general  texts.  Design  and 
analysis  examples  are  included,  as  are  several  real-world  examples  of  violations  of 
human  factors  principles. 

System  Design  and  Evaluation;  Sara^Czaja;  1997.  In  G.  Salvendy  (Ed.),  Handbook  of 
Human  Factors  and  Ergonomics  (2nd  ed.)  (pp.  17-40). 

This  book  chapter  provides  a  brief  overview  of  system  design  and  presents  a  discussion 
of  different  approaches  to  system  design  that  address  the  presence  and  role  of  humans 
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within  the  system.  The  basic  human  factors  activities  in  system  design  and  test  and 
evaluation  are  also  described. 

Allocation  of  Functions:  Joseph  Sharit;  1997.  In  G.  Salvendy  (Ed  ),  Handbook  of 
Human  Factors  and  Ergonomics  (2nd  ed.)  (pp.  301-339). 

Part  of  a  section  on  job  design,  this  book  chapter  discusses  the  importance  of  human- 
machine  allocation  of  functions  during  system  design.  Different  procedures  for  function 
allocation  are  covered,  as  are  implications  for  dynamic  allocation  -  the  transfer  of 
functions  between  humans  and  machines  during  system  operation.  The  issues  of  trust 
and  confidence  in  automated  systems  are  also  covered. 
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